【WEB安全】session 与 token 相关知识点

session

许多语言在网络编程模块都会实现会话机制，即 session。利用 session，我们可以管理用户状态，比如控制会话存在时间，在会话中保存属性等。其作用方式通常如下：

• 服务器接收到第一个请求时，生成 session 对象，并通过响应头告诉客户端在 cookie 中放入 sessionId
• 客户端之后发送请求时，会带上包含 sessionId 的 cookie
• 服务器通过 sessionId 获取 session ，进而得到当前用户的状态（是否登录）等信息

也就是说，客户端只需要在登录的时候发送一次用户名密码，此后只需要在发送请求时带上 sessionId，服务器就可以验证用户是否登录了。

session 存储在内存中，在用户量较少时访问效率较高，但如果一个服务器保存了几十几百万个 session 就十分难顶了。同时由于同一用户的多次请求需要访问到同一服务器，不能简单做集群，需要通过一些策略（session sticky）来扩展，比较麻烦。

之前见过有的人把 sessionId 持久化到数据库里，只存个 id，大头还在内存里，这个操作我是看不懂的。。。

- token

虽然 session 能够比较全面地管理用户状态，但这种方式毕竟占用了较多服务器资源，所以有人想出了一种无需在服务器端保存用户状态（称为 “无状态”）的方案，即使用 token（令牌）来做验证。

对于 token 的理解，比较常见的误区是：

• 生成方面，使用随机算法生成的字符串、设备 mac 地址甚至 sessionId 作为 token。虽然从字面意思上讲这些也算是“令牌”，但是毫无意义。这是真的 “没有状态” 了，对于状态的控制甚至需要用 session 完成，那只用 session 不好吗？
• 验证方面，把 token 存储在 session 或数据库中，比对前端传来的 token 与存储的 token 是否一致。鬼鬼，同样的骚操作。更骚的是为了提高比对效率把 token 存储在 redis 中，大家一看哇偶好高端好有道理，就直接采用这种方法了，甚至都懒得想 token 到底是个什么。。

简单来说，一个真正的 token 本身是携带了一些信息的，比如用户 id、过期时间等，这些信息通过签名算法防止伪造，也可以使用加密算法进一步提高安全性，但一般没有人会在 token 里存储密码，所以不加密也无所谓，反正被截获了结果都一样。（一般会用 base64 编个码，方便传输）

在 web 领域最常见的 token 解决方案是 JWT（JSON Web Token），其具体实现可以参照官方文档，这里不再赘述。

token 的安全性类似 session 方案，与明文密码的差异主要在于过期时间。其作用流程也与 session 类似：

• 用户使用用户名密码登录，服务器验证通过后，根据用户名（或用户 id 等），按照预先设置的算法生成 token，其中也可以封装其它信息，并将 token 返回给客户端（可以设置到客户端的 cookie 中，也可以作为 response body）
• 客户端接收到 token，并在之后发送请求时带上它（利用 cookie、作为请求头或作为参数均可）
• 服务器对 token 进行解密、验证

token 的优势是无需服务器存储！！！