理解session、token、cookie、JWT

Tags: 鉴权, 项目内容

Published: 2024年6月22日

Cookie

• cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。
• cookie 由服务器生成，发送给浏览器，浏览器把 cookie 以 kv 形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该 cookie 发送给服务器。由于 cookie 是存在客户端上的，所以浏览器加入了一些限制确保 cookie 不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的 cookie 数量是有限的。

Session

概念

Session（会话）是在客户端和服务器之间保持状态的机制，通常用来存储用户会话信息，如登录状态。

工作机制

• 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
• 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
• 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
• 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

优点：

• 简单易用，适合单机应用。
• 服务器端存储会话信息，便于管理和控制。

缺点：

• 依赖服务器存储，无法跨服务器或跨数据中心共享会话状态（除非使用共享存储）。
• 对于大型分布式系统，扩展性较差。

Token

工作机制

• 客户端使用用户名和密码请求登录。
• 服务端收到请求，验证用户名和密码。
• 验证成功后，服务端会签发一个token，再把这个token返回给客户端。
• 客户端收到token后可以把它存储起来，比如放到cookie中。
• 客户端每次向服务端请求资源时需要携带服务端签发的token，可以在cookie或者header中携带。
• 服务端收到请求，然后去验证客户端请求里面带着的token，如果验证成功，就向客户端返回请求数据。

优点：

• 无状态，客户端持有 Token，不依赖服务器存储会话信息，适合分布式系统。
• 易于扩展，Token 可以在不同服务之间共享认证信息。

缺点：

• Token 一旦泄露，可能被滥用。
• Token 的管理和刷新需要额外的机制。

JWT

概念

JWT 是一种基于 JSON 的开放标准（RFC 7519），用于在各方之间传递声明信息。通常用于身份认证和信息交换。

工作机制

JWT由三部分组成:头部(Header)、载荷(Payload)和签名(Signature)。它们通过点号"."分隔。

1. 头部(Header):头部通常由两部分组成，声明使用的加密算法和类型。例如:{"alg":"HS256","typ":"JWT"}

这个头部使用Base64编码后会成为JWT的第一部分

1. 载荷(Payload):载荷是]WT的第二部分，包含了需要传输的用户信息和其他声明。例如:{"sub":"1234567890""name": "John Doe","admin": true}。

载荷也会经过Base64编码，

1. 签名(Sianature):签名是JWT的第三部分，用于验证JWT的真实性和完整性。签名使用头部和载荷，以及预先约定的密钥(只有服务器知道)进行加密。

加密后的签名会与头部和载荷一起组成JWT的第三部分。

当客户端发送请求时，将JWT放在请求的头部(通常是"Authorization"字段)，服务器收到请求后，会对]WT进行解析和验证。通过对比签名和验证密钥，服务器可以确定JWT是否被篡改过，从而判断请求的合法性。这就是JWT的简单原理，它通过在客户端和服务器之间传递可信的JSON令牌来进行身份验证和授权。

JWT与其他认证技术的比较比如cookie和session相比有什么优势?

JWT 天然具有完美的水平扩缩能力，JWT令牌是多方系统中一种优秀的凭证载体，它不需要任何一个服务节点保留任何一点状态信息，就能够保障认证服务与用户之间的承诺是双方当时真实意图的体现，是准确、完整、不可改、且不可抵赖的。同时，由于 JWT本身可以携带少量信息，这十分有利于 RESTfUI API 的设计，能够较容易地做成无状态服务，在做水平扩展时就不需要像前面 Cookie-Session 方案那样考虑如何部署的问题。

JWT有哪些缺点

• **令牌难以主动失效:**JWT 令牌一旦签发，理论上就和认证服务器再没有什么瓜葛了，在到期之前就会始终有效，除非服务器部署额外的逻辑去处理失效问题，这对某些管理功能的实现是很不利的。譬如一种颇为常见的需求是:要求一个用户只能在一台设备上登录，在 B设备登录后，之前已经登录过的 A 设备就应该自动退出。如果采用 JWT，就必须设计一个"黑名单”的额外的逻辑，用来把要主动失效的令牌集中存储起来，而无论这个黑名单是实现在 Session、Redis 或者数据库中，都会让服务退化成有状态服务，降低了JT 本身的价值，但黑名单在使用 JT 时依然是很常见的做法，需要维护的黑名单一般是很小的状态量，许多场景中还是有存在价值的。
• **只能携带相当有限的数据:**HTTP 协议并没有强制约束 Header 的最大长度，但是，各种服务器、浏览器都会有自己的约束，譬如 Tomcat 就要求 Header 最大不超过 8KB，而在 Nginx 中则默认为 4KB，因此在令牌中存储过多的数据不仅耗费传输带竞，还有额外的出错风险。