为何说 Token 是 restful，而Cookie/SessionID 则不是？

Question

如果SessionID和Token都存在 redis 里让多个服务器共享
那没什么区别吧？

关于有无状态和是否restful
他们都需要在服务端保存信息，我觉得都是stateful
为何有的说Token就是stateless和restful，而Cookie/SessionID 则不是？

Answer 1

很多人是按session的方式来使用token，所以觉得两者一样。

session思维是这样：传递sessionID或者所谓的token到服务端，然后服务端根据这个键值找到用户数据，也许是session文件，也许在redis里，然后读取里面的数据uid=1，至此用户身份确立。

而真正的token思维是这样：uid=1直接保存在客户端，当然不会只保留这么简单的数据，很容易伪造。实际保存数据可能是这样uid=1|6166b2002fdcb5df，后面一部分签名是根据第一部分数据加密所得，而加密算法只有服务端知道，你就没办法伪造数据了。服务端获取这个token后，对第一部分数据验签，和第二部分比对，如果一致，直接确立用户身份uid=1。整个操作直接在内存中运算，不需要读取session文件或redis。你甚至可以把整个用户信息uid=1&nickname=xxx&money=1000保存到token里。

比如常用的JWT，是用 . 分割成3部分，每部分再base64_encode，但思路是一样的。

Answer 2

问题的出处在哪里？谁这么说了？表示疑问。。
RESTful 的定义里有关于 token 的说法？
说我的理解吧，不管是 token 还是 session 都只是标识请求来源，是哪个用户请求的。
换种说法，网站的 api 实现，我明明可以用 session 的为什么要有 token ？多此一举 。

Answer 3

不管token很是session_id原理上都是差不多的，token通常是放在接口直接请求，token通常是放在header中进行请求，不管怎么样都需要前后端发起数据交互。不管用token还是session，都没大关系，只要能实现即可。

Answer 4

可以看下jwt这种token，是不需要存在服务器的，所有认证信息（用户id，过期时间等）是被加密在token当中的，在服务端解密token就可以获取认证信息，不像session需要在服务器那里，根据cookie来取回状态。

至于安全问题，jwt+https基本是很安全的了。这种stateless的token还有个好处是他可以无痛拓展，因为session的文件是存放到磁盘上的，当你有第二台服务器时，为了共享登陆，你不得不把session文件转移到redis或其他介质上，而jwt本身自带所有认证信息，直接使用

Answer 5

虽然我不是大神，但是可以介绍一个大神

Token 认证的来龙去脉 segmentfault.com/a/1190000013010835 by 边城

如果我们把所有状态信息都附加在 Token 上，服务器就可以不保存。但是服务端仍然需要认证 Token 有效。不过只要服务端能确认是自己签发的 Token，而且其信息未被改动过，那就可以认为 Token 有效——“签名”可以作此保证。平时常说的签名都存在一方签发，另一方验证的情况，所以要使用非对称加密算法。但是在这里，签发和验证都是同一方，所以对称加密算法就能达到要求，而对称算法比非对称算法要快得多（可达数十倍差距）。更进一步思考，对称加密算法除了加密，还带有还原加密内容的功能，而这一功能在对 Token 签名时并无必要——既然不需要解密，摘要（散列）算法就会更快。可以指定密码的散列算法，自然是 HMAC。

Answer 6

RESTful的定义是无状态，token更符合这一点，每次请求都传递参数token，无状态的交互形式。
而我们都知道http是无状态的，所以每次都要带上状态去请求服务器也就是 Cookie/SessionID，cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。