一文详解Token,Session,Cookie和JWT的区别

Cat凯94

已于 2023-05-26 15:14:05 修改

阅读量657

点赞数 1

分类专栏：计算机网络前端文章标签：前端网络

于 2023-04-06 19:31:21 首次发布

本文链接：https://blog.csdn.net/loseyourself94/article/details/129991986

版权

计算机网络同时被 2 个专栏收录

5 篇文章 0 订阅

订阅专栏

前端

1 篇文章 0 订阅

订阅专栏

背景

为了提高协议的可扩展性和灵活性，确保它可以适用于各种不同的应用场景,并且为了减轻服务器的负担，使其更加轻量级. HTTP是无状态的,在每次服务端接收到客户端的请求时，都会是个全新的请求，服务器并不知道这个请求是谁发起的，也不知道这个请求是不是第一次发起的，也不知道这个请求是不是最后一次发起的。这就意味着，每次请求都是独立的，服务器不会记录任何请求的信息，也不会记录任何客户端的信息。那么如何实现状态维持的呢?

简单来说,服务器可以给你发个通行证，这样你可以拿着通行证，在这个网站里到处逛。因此，诞生了这一系列的设计，从网景公司发明的 Cookie，到后来Session、LocalStorage、IndexDB 等技术，都为客户端处理状态信息提供了很多的解决方案。

Cookie是浏览器实现的一种数据存储技术。一般由服务器生成，发送给浏览器（客户端也可进行Cookie设置）进行存储，下一次请求同一网站时会把该Cookie发送给服务器。

作用

会话管理:登陆、购物车、游戏得分或者服务器应该记住的其他内容
个性化:用户偏好、主题或者其他设置
追踪:记录和分析用户行为

特点

Cookie存储在客户端（浏览器），发送请求时自动携带放在请求头中。
Cookie只能以文本的方式保存字符串类型的数据。
单个Cookie保存的数据不能超过4KB。
Cookie的安全性不高，别人可以分析存放在本地的Cookie并进行Cookie欺骗。
- Cookie 劫持
- XSS 攻击
Cookie默认不可跨域，可通过特殊的操作如:设置withCredentials属性为true实现跨域。

应用场景

在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了。除此之外，Cookie 还能保存用户首选项，主题和其他设置信息。
使用Cookie 保存 Session 或者 Token ，向后端发送请求的时候带上 Cookie，这样后端就能取到session或者token了。这样就能记录用户当前的状态了，因为 HTTP 协议是无状态的。
Cookie 还可以用来记录和分析用户行为。例如在网上购物的时候，因为HTTP协议是没有状态的，如果服务器想要获取你在某个页面的停留状态或者看了哪些商品，一种常用的实现方式就是将这些信息存放在Cookie

Session

Session 是另一种记录服务器和客户端会话状态的机制，并且Session 是基于 Cookie 实现的。服务器要知道当前请求发给自己的是谁，为了做这种区分，服务器就是要给每个客户端分配不同的"身份标识"，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”。

Session是 Web 应用程序中常用的会话跟踪机制。它是一种在服务器端存储用户状态信息的机制，通常用于存储用户的身份认证信息、会话标识符等敏感数据。它与 Cookie 不同，Session 会将用户的数据存储在服务端，并且会根据加密算法确保它的安全性。

特点

Session 是基于 Cookie 实现，Cookie失效或删除则Session也无法获取。
Session 是存储在服务器端，所以安全性比Cookie高。
Session 可以存任意数据类型。
Session的默认生效时间是30分钟。只要在生效时间内，即使该Session值已被修改，依然可通过旧有Cookie访问到旧有Session值。
Session 可存储数据的容量远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

Session和Cookie的对比

	Cookie	Session
存放位置	客户的浏览器	服务器
安全性	不安全	安全
数据大小	不能超过4K	无数据类型和大小限制
生命周期	预先设置的生存周期，或永久的保存于本地的文件	IE启动到IE关闭

不足

都基于浏览器 Cookie 实现，用户禁用 Cookie 后，系统就无法正常使用了。
虽然Session具备一定的安全性，但是它的问题在于扩展性不好。比如涉及到服务器集群的场景，要求每台服务器都能够读取Session。这种场景一般解决方案是Session共享，经典应用需求是A和B两个关联网站间的单点登录，但是这种方案一般工程量较大
Session信息存到服务器，必然占用内存。用户多了以后，开销必然增大。为了提高效率，需要做分布式，做负载均衡。因为认证的信息保存在内存中，用户访问哪台服务器，下次还得访问相同这台服务器才能拿到授权信息，这就限制了负载均衡的能力。而且SeesionID存在Cookie，还是有暴露的风险，比如CSRF（Cross-Site Request Forgery，跨站请求伪造）

如何解决这些问题呢？基于Token令牌鉴权

Token

一种不需要自己存放 Session 信息就能实现身份验证的方式，通过这种方式服务器端就不需要保存 Session 数据了，只用在客户端保存服务端返回给客户的 Token 就可以了，扩展性得到提升。

特点

Token不需要再存储用户信息，节约了内存,token签发后存储在客户端，不占用服务器资源，可减轻服务器压力
由于不存储信息，客户端访问不同的服务器也能进行鉴权，增强了扩展能力(解决跨域)
Token可以采用不同的加密方式进行签名，提高了安全性
每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里

Token传递的过程跟Cookie类似，只是传递对象变成了Token。用户使用用户名、密码请求服务器后，服务器就生成Token，在响应中返给客户端，客户端再次请求时附带上Token，服务器就用这个Token进行认证鉴权。

Token虽然很好的解决了Session的问题，但仍然不够完美。服务器在认证Token的时候，仍然需要去数据库查询认证信息做校验。为了不查库，直接认证，JWT出现了。

JWT

JWT （JSON Web Token）通常可以称为 Json 令牌,本质上就是一段签名的 JSON 格式的数据。由于它是带有签名的，因此接收者便可以验证它的真实性。

JWT是RFC 7519 中定义的用于安全的将信息作为 Json 对象进行传输的一种形式。JWT 中存储的信息是经过数字签名的，因此可以被信任和理解。可以使用 HMAC 算法或使用 RSA/ECDSA 的公用/专用密钥对 JWT 进行签名。

作用

认证(Authorization)：这是使用 JWT 最常见的一种情况，一旦用户登录，后面每个请求都会包含 JWT，从而允许用户访问该令牌所允许的路由、服务和资源。单点登录是当今广泛使用 JWT 的一项功能，因为它的开销很小。
信息交换(Information Exchange)：JWT 是能够安全传输信息的一种方式。通过使用公钥/私钥对 JWT 进行签名认证。此外，由于签名是使用 head 和 payload 计算的，因此你还可以验证内容是否遭到篡改。

内容

Header :描述 JWT 的元数据。定义了生成签名的算法以及 Token 的类型。
Payload（负载）:用来存放实际需要传递的数据(一般是Base64Url编码完成)
Signature（签名）：服务器通过Payload、Header和一个密钥(secret)使用 Header 里面指定的签名算法（默认是 HMAC SHA256）生成。

在服务器端需要存储以下信息：

JWT的密钥：用于对JWT进行加密和解密，要保证密钥的安全性，不能外泄。
用户信息：JWT通常用来进行用户身份认证和授权，所以一般需要在服务端存储一些和用户相关的信息。通常，JWT中存储了用户的 id、用户名、角色等信息，服务器端需要将这些信息存储在用户的会话中，以便进行后续的鉴权验证。
过期时间：JWT需要设置过期时间，以保证安全性。因为JWT中的信息是经过加密的，无法修改，因此过期时间只能是JWT生成时设置，需要在服务器端存储JWT的生成时间和过期时间。

使用场景

JWT一般可暂时存储在localstorage或Cookie中方便获取:

将JWT放在Cookie 里面自动发送，缺点是默认不可跨域。
将JWT放在HTTP 请求头信息的 Authorization 字段里（主流做法）。
JWT就放在POST请求的数据体里。
JWT放在GET请求的参数里（即URL里）

JWT和Session的对比

	JWT	Session
存放位置	客户的浏览器	服务器
加密签名	有	无
可扩展性	强	弱
跨域认证	支持	不支持

解决跨域问题

单点登录需求:多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

这种需求需要解决跨域认证 以及前端页面 JavaScript 跨域 问题,本文简单介绍跨域认证解决方式

Session持久化

如果采用传统的Session用户验证机制，则需要Session实现多系统共享。那么标准的实现方案就是将 Session 数据持久化，写入数据库或别的持久层。各种服务受到请求后，都向持久层请求数据。

具体实现流程：

用户在A网站登录成功后，将 session 存储到 Redis 持久化存储，注意设置有效期。
此时访问网站B 进行用户身份认证。注意此时访问 B的链接URL 要携带参数 sessionId！B 在处理请求- 身份验证时，先解析是否携带了sessionid参数，携带了则向 redis 中查询相关数据，并将数据保存到当前会话中。此时就成功登录 B 了。