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

Question

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

似乎做APP都会用token这方式

Answer 1

先说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 2

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

Answer 3

RESTful Api 中应该如何设计权限认证 《理解OAuth2.0》

Answer 4

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

Answer 5

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