JWT和Session和Cookie

最新推荐文章于 2025-08-31 21:46:37 发布

原创最新推荐文章于 2025-08-31 21:46:37 发布 · 822 阅读

本内容遵循CC 4.0 BY-SA版权协议

本文详细介绍了HTTP会话管理中的Cookie、Session和JWT（Json Web Token）的工作原理、优缺点以及应用场景。Cookie将信息保存在客户端，安全性较低；Session将信息保存在服务端，但会增加服务器压力；JWT将信息存储在JSON字符串中，无状态且支持跨域，但存在一次性问题、续签问题和安全问题。同时，文中还探讨了Token如何防止CSRF攻击及其工作原理。

会话管理

由于HTTP请求是无状态的，也就是说，每一个请求是相互独立的，互不干涉，但是在实际应用场景中，这个显然是不符合要求的。所以使用HTTP+状态管理进行一个面向用户Web开发。
这几个技术都是对HTTP协议的一个补充。

cookie

使用cookie进行会话管理的时候，我们会将用户信息或其他我们需要放在每个请求的一小段信息放入到cookie中进行保存，cookie是放在请求头中的，然后每次请求的时候会将cookie中的信息放入请求头中，在服务端进行验证，以此来进行状态的保证。

Session

使用session进行会话管理的时候，只需要在客户端保存一个sessionid即可，而用户信息是存放在服务端中的，当用户登陆时，会将用户信息存放在服务端，然后对应生成一个sessionid保存在客户端中

一般可将sessionid存放在cookie中。

session和cookie的优缺点

cookie的安全性不好，攻击者可以获得本地cookies进行欺骗或者使用cookies进行进行CSRF攻击。
cookies不支持跨域（原因：因为当一个浏览器存在多个域名的cookie时，比如baidu.com和google.com两个cookies时，因为域名不同（一棒子打死的感觉，只要域名不同就不会携带），所以访问baidu时是不会携带google的cookies的，这样的话，当访问www.google.com和image.google.com时）虽然同属于google，但是因为域名不同，所以也是不能访问的，这显然是不符合我们预计的效果的，所以一般需要对跨域进行一个处理（domain）。
session因为是将会话信息保存在服务端，所以当存在大量用户的时候，对服务器的压力也是一方面的考验。
同时当存在多个机器的时候，session的会话共享也是一个问题。比如用户登陆通过服务器A，然后发送请求时，用的是服务器B，那么如何知道这个用户。（Redis）

在这里插入图片描述

JWT

JWT全名Json Web Token，由三部分组成:

header
payload
signature

header中通常来说由token的生成算法和类型组成。如：

{
    "alg":"HS256",
    "typ":"JWT"
}

payload中则用来保存相关的状态信息。如用户id，role，name等。

{
    "id": 10111000,
    "role": "admin",
    "name": "Leo"
}

signature部分由header，payload，secret_key三部分生成，其生成公式为：

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret_key)

再将这三个部分组合成header.payload.signature的形式。这个组合即为token。

JWT工作

首先用户发出登录请求，服务端根据用户的登录请求进行匹配，如果匹配成功，将相关的信息放入payload中，利用上述算法，加上服务端的密钥生成token，这里需要注意的是secret_key很重要，如果这个泄露的话，客户端就可以随意篡改发送的额外信息，它是信息完整性的保证。生成token后服务端将其返回给客户端，客户端可以在下次请求时，将token一起交给服务端，一般来说我们可以将其放在Authorization首部中，这样也就可以避免跨域问题。接下来，服务端根据token进行信息解析，再根据用户信息作出相应的操作。

JWT的优缺点

优点

通过JWT的实现可以看出，上述的cookie和session的问题都不存在了，安全性提高，不易被攻击者利用。利用Authorization首部传输token，无跨域问题。额外信息存储在客户端，服务端占用资源不多，也不存在session共享问题。

支持跨域
无状态（指不需要在服务端保存信息）
性能（Cookie认证要比Token认证慢很多，因为Cookie使用寻找session，则token解密即可）

缺点

一次性问题

续签问题，token的刷新
如果你使用jwt做会话管理，传统的cookie续签方案一般都是框架自带的，session有效期30分钟，30分钟内如果有访问，有效期被刷新至30分钟。一样的道理，要改变jwt的有效时间，就要签发新的jwt。最简单的一种方式是每次请求刷新jwt，即每个http请求都返回一个新的jwt。这个方法不仅暴力不优雅，而且每次请求都要做jwt的加密解密，会带来性能问题。另一种方法是在redis中单独为每个jwt设置过期时间，每次访问时刷新jwt的过期时间。
主动注销问题
无法废弃
通过上面jwt的验证机制可以看出来，一旦签发一个jwt，在到期之前就会始终有效，无法中途废弃。例如你在payload中存储了一些信息，当信息需要更新时，则重新签发一个jwt，但是由于旧的jwt还没过期，拿着这个旧的jwt依旧可以登录，那登录后服务端从jwt中拿到的信息就是过时的。为了解决这个问题，我们就需要在服务端部署额外的逻辑，例如设置一个黑名单，一旦签发了新的jwt，那么旧的就加入黑名单（比如存到redis里面），避免被再次使用。

安全
由于jwt的payload是使用base64编码的，并没有加密，（解决，可以将payload进行加密）因此jwt中不能存储敏感数据。而session的信息是存在服务端的，相对来说更安全。
性能
jwt太长由于是无状态使用JWT，所有的数据都被放到JWT里，如果还要进行一些数据交换，那载荷会更大，经过编码之后导致jwt非常长，cookie的限制大小一般是4k，cookie很可能放不下，所以jwt一般放在local storage里面。并且用户在系统中的每一次http请求都会把jwt携带在Header里面，http请求的Header可能比Body还要大。而sessionId只是很短的一个字符串，因此使用jwt的http请求比使用session的开销大得多。
cookie和session storage和local storage都可以在开发者工具那里看到。session storage可以设置有效时间，关闭浏览器就失效。
local storage关闭浏览器不会失效。

为什么Token可以防止CSRF

token不是为了防止XSS的，而是为了防止CSRF的；

CSRF攻击的原因是浏览器会自动带上cookie，而不会带上token；

以CSRF攻击为例：

cookie：用户点击了链接，cookie未失效，导致发起请求后后端以为是用户正常操作，于是进行扣款操作；
token：用户点击链接，由于浏览器不会自动带上token(token需要前端代码携带)，所以即使发了请求，后端的token验证不会通过，所以不会进行扣款操作；

这也是为什么token放在header的Authorization中，而不放在cookie中，放在cookie中就没有意义了，也可以被获得。另一个原因是如果token过长，cookie可能放不下。

CSRF工作原理

用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

总结

无论session还是cookies或是jwt。目前情况是jwt仍然无法代替session，cookies也会有人用。它们各自有自己的优势和缺点，不能因为有一些缺点就否认技术的存在，缺点仍然可以采用一些技术手段来弥补，比如通过添加csrf token来阻止来自CSRF的攻击，比如利用redis集群来做session的存储和共享。技术只是工具，选择最适合你的才是最重要的。
在这里插入图片描述
Cookies是将会话信息存放在客户端，Session是将会话信息存放在服务端，然后在客户端存一个sessionId，JWT是将用户信息存放到自己的JSON字符串中，每次对字符串进行解析，进而鉴权。