为什么 APP 要用 token 而不用 session 认证？

@SoloCompany
+1

如果lz说的是OAuth Token的话，这货在本质上还是session identifier，那么和普通session id的区别也就只是获得这个token的过程不同。

ls有人说什么token需要才传，不需要不传，那session id不是么？说得好像用了OAuth，HTTP就不是stateless的了一样。

可以对比一下三种认证方式的区别，这也是很基础的事情了
1. basic auth
没有安全性可言，完全依赖 https，并且每次请求都需要传递密码，是最不安全的

2. session
一般需要 basic auth 或其它 auth 方式先进行身份认证后才能建立，和 basic auth 一样没有什么安全性可言，需要 https 保障，只不过避免了每次传递密码（忽略服务器端状态这点特性）

3. oauth
部分是为了解决 basic auth 的安全问题而设计的，但是要复杂很多，即使没有https也能保证基本的安全，数据包被监听后不能防止信息泄露，但可以防止信息伪造，包括重放攻击

@SoloCompany 分类分错了

Authentication是Authentication，Session是Session。

你上面分别说了两种验证方式和一种标记方式。

@raincious 严格说是这样的，但在实际场景中就是先认证建立session，然后之后的通讯是基于session来代替身份认证，广义来说也算是一种认证方式也没什么错，泄露了session cookie就基本上身份被盗取了

能弱弱地问一下大家token怎么设计生成，服务端应怎样处理么，新手求指导

session 这里是指http session吧。
app 这服务器交互不一定只有http协议一条路吧。

@SoloCompany

其实你这样理解是将“用户登录系统”看成一个整体了。但事实上“用户登录系统”可以是由Auth + Session组成的。

Auth的方式比如OAuth和Basic Auth甚至Get参数Auth诸如此类。但是Auth系统在Auth过程之后就完成操作了，剩下的继续由“用户登录系统”交给Session或者Token来实现用户绑定。

比如：
https://gist.github.com/raincious/2820fd0b85511adc3ef2

注意Session可以不需要验证用户是否合法，它只需要查询自身数据（SessionID之类）是否合法，因为它用到的用户数据本身就（应当）是来自程序的运算结果，可以看作是信任数据。

事实上TokenID也可以看做SessionID，但是这完全取决于你如何实现你的系统。现在好像没有一个统一的规范说“Token”这个词必须用在某种格式的数据上。于是乎你可以拿Token放在Json里当SessionID用（相当于从HTTP Header里换到了HTTP Body里），也可以像@akfish提到的JWT那样用。这完全取决于需求和决定。

session 和 token 就是个词而已…… 广义来说一切维护用户状态的技术都是session，一切动态生成的服务端有能力鉴别真假而本身无涵义的字符串都是token

这注定是个鸡同鸭讲的主题，我都不知道我为啥要回复了

都是唯一值，有什么区别。。。。

@SoloCompany 这里的token和OAuth没什么关系吧?

@mcfog 新手比较糊涂嘛，我觉得道理是这么回事，能不能具体说说现在APP一般的auth流程实现，包括登陆状态的保持。

SessionId不就是Token……

iOS这边我倒是可以说说
Cookie验证对于iOS来说很是繁琐的，比如说有些接口不需要验证，或者说就不能加上验证的，用Cookie的话也会自动发过去，需要手动清除Cookie，之后再添加；但是用Token就比较好控制发还是不发，毕竟是GET或者POST参数嘛
再一个麻烦的就是Cookie在App关闭在开启之后会被重置，这个时候就需要做很多缓存的工作了，比较头疼，不如Token直接存在Keychain里面，每次要用的时候读取来的方便

我默认楼主说的Session是储存在Cookie里面的，因为我只做过这种的……
不过可能还是有理解误差……

现在很多Web App也是基于token了。参考jwt

Session 是一种HTTP存储机制，目的是为无状态的HTTP提供的持久机制。所谓 Session 认证只是简单的把 User 信息存储到 Session 里，因为 SID 的不可预测性，暂且认为是安全的。这是一种认证手段。

而 Token ，如果指的是 OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对 App 。其目的是让 某App 有权利访问 某用户 的信息。这里的 Token 是唯一的。不可以转移到其它 App 上，也不可以转到其它 用户 上。

转过来说 Session 。Session 只提供一种简单的认证，即有此 SID ，即认为有此 User 的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方App。

所以简单来说，如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。
如果永远只是自己的网站，自己的 App ，用什么就无所谓了。

楼主这么纠结干什么呀,client端登陆后server端给个Identity,下次client去服务器取数据的时候带上这个Identity就是了.至于这个Identity放在哪儿,server能拿到就是了.

@mkeith 那么问题来了，我后台想要同时给web和app提供服务应该怎么办？

顶36楼，另附一篇对比session和token的文章https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

一个注重状态，一个注重授权。有什么问题吗？