php - 基于 session 和基于 token 的用户认证方式到底该如何选择？

Question

我的理解：
虽然确实都是“客户端记录，每次访问携带”，但 token 很容易设计为自包含的，也就是说，后端不需要记录什么东西，每次一个无状态请求，每次解密验证，每次当场得出合法 /非法的结论。这一切判断依据，除了固化在 CS 两端的一些逻辑之外，整个信息是自包含的。这才是真正的无状态。
而 sessionid ，一般都是一段随机字符串，需要到后端去检索 id 的有效性。万一服务器重启导致内存里的 session 没了呢？万一 redis 服务器挂了呢？

似乎做APP都会用token这方式

Answer 1

做服务一般都会用 token 来作为有效凭证，题主说的 session 先不说意外情况，光是吃内存就受不住

Answer 2

先说Session

HTTP都是无状态的，所以HTTP服务器是不知道你发的这个请求和上一个请求有什么关联性。

『给我来份煎饼』『好』
『鸡蛋』『鸡蛋？』
『再加个鸡蛋』『刚才你点的啥？』

最终得到一份普通煎饼，外加两个疑问

为此引入了Session概念，即服务端和客户端都保存一段文本，每次交互都带着，这样服务器就知道客户端是刚才的那个谁了。

『给我来份煎饼』『好』
『鸡蛋，我是刚才要煎饼那个』『好』
『再加个鸡蛋』『好』

最终得到一份加了两个鸡蛋的豪华煎饼

如果服务器重启或者因为其他理由，Session丢失，那就没了。用户需要重新登录和认证。

『给我来份煎饼』『好』
『鸡蛋，我是刚才要煎饼那个』『好』
…………一阵大风，煎饼摊翻了
『给我来份煎饼』『好』……

再说OAuth2

OAuth2其实没有Session强大，OAuth2的accessToken只能做到 token字符串 → ID + Scope 的程度，scope不知道的话，可以暂时理解为一个权限控制。

OAuth2不能保存状态信息，每一次请求都视为全新请求。

『给我来份煎饼（token我是你对面摊卖烤冷面的，scope赊账）』『好』
『鸡蛋（token我是你对面摊卖烤冷面的，scope赊账）』『好』
『再加个鸡蛋（token我是你对面摊卖烤冷面的，scope赊账）』『好』

最终得到一份普通煎饼，外加两个鸡蛋……

如果服务器重启或者因为其他理由，服务器端的OAuth2已保存数据丢失，那就没了。用户需要重新登录和认证。

『给我来份煎饼（token我是你对面摊卖烤冷面的）』『那个……我没见过你』

总结

这两个玩意虽然都能实现用户认证，但是涉及的范围完全不一样。

Session不仅可以包含认证，还能覆盖非常多的会话相关功能。

Answer 3

RESTful Api 中应该如何设计权限认证

《理解OAuth2.0》

Answer 4

sessionid其实就是token的一种形式，服务器端当然要保存这个token了，自包含会带来很多问题，比如用户得知自己账号被黑时，就没法把这个token禁掉了(除非把这个用户禁掉)。

至于token在服务器中怎么存，有很多种办法，比如本机内存、中央缓存(如redis)、数据库等等。不必担心存储挂掉的问题，现在成熟的解决方案有很多。

即便是Tomcat(或其他HTTP服务器)的session，也有很多种存储方式，默认是本机内存+序列化到磁盘文件，也可以配置成多机共享、中央缓存、数据库等等。

无论是session还是token，都应该根据访问量、时效等因素来决定存储方式。

Answer 5

层次不一样，session是代表会话，token代表权限，多数系统将权限和会话混为一潭，或者将权限放到会话下面，导致没有很好区分这个概念。比如匿名用户也有会话，会话结束仍然有权限。

Answer 6

你说的情况token并不能解决。。。token也是需要服务端存储的，因为token里面可能包含了很多的信息，权限，过期时间等等，所以也是需要存储的。