Cookie/session/token/jwt

1. cookie

• 长度有限制，一般最大4k，存储在浏览器在中，受同源策略限制，不能跨域访问。
• 一般是明文传输，容易被篡改，不要在里面放用户名、密码等敏感信息。
• 每次请求，浏览器会自动带上cookie。

2. session

• 存储在服务端，占用服务端的资源。
• 客户端通过cookie中的会话id与服务端的session关联，也可以把sessionId放到url、隐藏表单中传给服务端。
• 相对安全，因为关键信息都存储在服务器端。

3. token

• 客户端每次请求都带上token，服务器通过一定的规则来校验token，以此验证用户身份。
• 单点登录SSO一般用token来实现。

4. jwt

• 值是json格式的，作用跟token类似。
• 通常存储在客户端，每次http请求的时候带上，通常放在http header中的authorization中。
• jwt分成3个部分：
  • 头部：包含Token类型（通常是JWT）和使用的加密算法。
  • 载荷：包含用户的身份信息、权限、过期时间等声明（Claims）。
  • 签名：由头部和载荷通过指定的加密算法生成，用于验证 Token 的完整性和真实性。

5. 相同和不同

5.1. sessionId和token

• 相同之处：都可以用于客户端和服务器之间的用户身份识别和用户会话机制。用户登录后，服务端生成一个唯一的标识，可以是token或SessionId，在后续的请求中，客户端将这个标识发送给服务器。
• 不同之处：
  • sessionId需要与服务器上的session对象关联，服务器需要维护session的生命周期，所以会占一些内存；token只需要服务端按逻辑校验token的合法性即可，不会占太多服务器的内存。
  • session对象是一个服务器上生成的，所以在集群场景下，其他机器也要共享到这个session的状态，比如加分布式缓存之类的；token不会在服务器上存储状态，所以集群场景下扩展性很好。

5.2. 存储位置

• Cookie存储在浏览器端；
• Session存储在服务器端；
• Token和JWT可存储在客户端(如浏览器本地存储或Cookie中)，也可以在请求中作为Authorization头的一部分发送。

5.3. 安全

• Cookie相对较不安全，容易被窃取；
• Session存储在服务器端相对安全，但如果服务器被攻击，Session数据也可能泄露；
• Token和JWT通过加密和签名等方式提高了安全性，但如果密钥泄露，也会存在风险。

5.4. 可扩展性

• Token和JWT适合分布式和微服务，因为它们可以在多个服务之间共享，不依赖服务器端的Session；
• Cookie和Session在跨域场景下可能会受到限制。

5.5. 生命周期管理

• Cookie和Session的生命周期可以由服务器控制，但需要考虑浏览器的行为和会话超时等因素；
• Token和JWT的生命周期由其自身的过期时间决定，客户端需要在Token过期前重新获取新的Token。