【前端知识】Cookie, Session,Token和JWT的发展及区别（四）

xiaobai_Ry

已于 2023-05-20 17:07:18 修改

阅读量1.4k

点赞数 6

分类专栏：前端知识点文章标签：前端 Token JWT Session Cookie

于 2023-05-20 16:57:47 首次发布

本文链接：https://blog.csdn.net/qq_41895003/article/details/130567062

版权

前端知识点专栏收录该内容

15 篇文章 3 订阅

订阅专栏

【前端知识】Cookie, Session,Token和JWT的发展及区别（四）

9. JWT
10. 拓展——安全
11. 总结
12. 其他

承接上文的笔记继续分享啦。

由于篇幅有点长😂，所以笔者将我关于这部分的笔记分为四个篇章（文章开头后面附录上下篇链接），避免读者的阅读疲倦感😵，同时也方便大家的阅读啦🤗。如果下面笔记中存在错误，欢迎大家及时指正，学习与讨论。

上章：主要介绍一下背景和Cookie。
链接：【前端知识】Cookie, Session,Token和JWT的发展及区别（一）
中章：主要介绍一下Session并总结一下Cookie和Session。
链接：【前端知识】Cookie, Session,Token和JWT的发展及区别（二）
下章：主要介绍Token的相关定义及理解
链接：【前端知识】Cookie, Session,Token和JWT的发展及区别（三）
终章：主要介绍JWT并总结JWT和Token的区别，以及总结Cookie到JWT的区别与发展。
链接：【前端知识】Cookie, Session,Token和JWT的发展及区别（四）

9. JWT

9.1 JWT的背景及定义

（1）JWT的字面理解

JWT是JSON Web Token的缩写，从字面上来看，我们也可以知道JWT的数据格式为JSON对象，而且它也是一种特殊的Token。简单来说，JWT是一种使用JSON格式传递数据的Web Token技术。跟Token一样，JWT可用于用户的登录鉴权，是一种用于身份验证和授权的开放标准，定义了一种紧凑简约、自包含的协议格式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。

1. 紧凑简约（Compact）：实际上指的是JWT是轻量级的，由于JWT是基于JSON的，尺寸相对较小，而且JWT可以通过URL，POST参数或HTTP标头内发送。
2. 自包含（Self-contained） : 指JWT的第二部分有效载荷（Playload）包含有关用户的所有必需信息，是一种自己包含用户信息及加密算法的数据。

（2）JWT与传统Token的区别

🤔那JWT与前面提到的Token有什么区别？
前面提到Token不是也是说避免多次查库吗？需要注意的是现在很多文章中讲到的Token更多的偏向JWT，而不是传统的Token。所以看文章时，需要注意一下这一点。因此，这里讨论的主要是JWT跟我们传统的Token的区别是什么。其实它们的区别主要体现在接收的信息是否需要进入数据库查询信息。传统的Token需要查库是因为它们通常采用的是基于带状态的用户认证机制，也就是我们前面所说的有状态的Token。在这种有状态的机制下，每个Token就必须与后端存储（比如数据库或者服务器缓存）进行交互，以此来验证Token的合法性和有效性。而我们现在所讲的JWT也就是我们前面所说的无状态Token啦。与传统的Token不同，JWT将用户信息加密到Token里面，服务器不保存任何用户信息，服务器通过使用保存密钥验证JWT Token的准确性，只要准确即可通过验证。

因此，JWT的出现改善了传统Token需要查库验证用户信息，而JWT不用查库或者少查库，直接在服务端进行校验。因为用户的信息及加密信息包含在JWT的第二分部Payload（有效荷载）和第三部分的Signature（签名）中，只要在服务端进行校验便可，并且校验也是JWT自己实现的。

这里JWT校验是JWT自己实现是指JWT校验过程中，检查JWT合法性的算法是服务器根据JWT中的规范来完成的。在验证JWT时，需要对比从请求中获取到的JWT前面和服务端根据相同的密钥计算出来的签名是否一致，所以我们通常说JWT校验是JWT自己实现，JWT自己提供签名及签名算法规范。

9.2 JWT的组成

JWT本质上是由三部分组成的字符串，包括 Header（头部）、Payload（有效荷载）和 Signature（签名）。
在这里插入图片描述 JWT三部分之间用“.”号做分割：

其中， Payload部分是真正的用户信息，是用户信息经过加密之后生成的字符串。而Header和Signature是与安全相关的部分，只是为了保证Token的安全性。

jwt token = base64 URL(头部) + "." +base64 URL(负载) + "." + base64 URL(签名)

注：Base64 URL是一种编码，不是加密方式，是可以解码的

🤔 那什么是Base64 URL编码和Base64编码？
Base64 编码和 Base64 URL 编码都是将二进制数据转换为可读字符串的编码方式，区别在于 Base64 URL 编码考虑了 URL 场景下的特殊性。

Base64 编码
是一种将二进制数据转化为可读字符串的编码方式，它使用 64 个 ASCII 字符来表示二进制数据中的每一个字节，并且可以减少数据在网络上的传输量。Base64 编码使用 “+”、“/” 和 “=” 三个字符，因此在URL 或 HTTP 报头等场景下可能会出现问题。
Base64 URL 编码
是正常 Base64 编码的变种，为了适应 URL 和 HTTP 报头等场景，其使用 “-” 和 “_” 替代 “+” 和 “/”，并且去掉了等于号“=”，不足4个字符时，补上需要加密的字符数模4的余数个"="号。这使得 Base64 URL 编码更加适合于在 URL 中传输二进制数据，而不会对 URL 的解析造成问题。

（1） Header（头部）

头部（Header）：JWT头部是一个描述JWT元数据的JSON对象, 一般在头部会说明签名的方法和令牌的类型。

作用：记录令牌类型、签名算法等例如：{“alg":“HS256”,“type”,"JWT}

	// JWT头部分是一个描述JWT元数据的JSON对象，通常如下所示。
	{
	"alg": "HS256",
	"type": "JWT"
	}
	// 1）alg属性表示签名使用的算法，默认为HMAC SHA256（写为HS256）；
	// 2）type属性表示令牌的类型，JWT令牌统一写为JWT。
	// 3）最后，使用Base64 URL算法将上述JSON对象转换为字符串保存。

（2）Payload（有效荷载）

有效载荷（Payload): 七默认字段+自定义私有字段
作用：携带一些用户信息，例如{“userId”:“1”,“username”:“mayikt”}，存放信息(可以被解密，不安全)，需要注意的是，Payload的内容只经过了 Base64 编码，对客户端来说当于明文存储，所以不要放置敏感信息。
七默认字段:
- iss: jwt签发者
- sub: jwt所面向的用户
- aud: 接收jwt的一方
- exp: jwt的过期时间，这个过期时间必须要大于签发时间
- nbf: 定义在什么时间之前，该jwt都是不可用的.
- iat: jwt的签发时间
- jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。

（3）Signature（签名）

Signature签名 = HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)
作用：防止Token被篡改、确保安全性。例如：计算出来的签名，一个字符串。Header和Playload加上密钥加密而成，用于比对信息，防止篡改Header和Playload。Signature需要使用编码后的header和payload,以及我们提供的一个密钥，然后使用header中的签名算法进行签名，签名的作用是保证JWT没有被篡改过
Signature中常用的签名算法：常见的算法加密方式有SHA，HMAC，RSA和ECDSA等。其中：
- SHA：是一种散列算法（哈希函数），可以细分为：SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。
- HMAC：是对称加密【哈希消息验证码】，加密和解密用的是相同的密钥，主要用于消息防篡改，例如：HMAC SHA256、HMAC SHA384 和 HMAC SHA512。
- RSA：是基于公私钥非对称加密的算法，在 JWT 中主要用作数字签名，算法运行较慢。RSA没有加入随机数，因此如果攻击者遍历猜测所有的原文，可以通过对比相同的加密密文选择出真实原文，为了防止这种情况，RSA加入了padding机制，对数据进行填充。
- ECDSA：是基于椭圆曲线密码学的非对称加密算法，在 JWT 中同样用作数字签名，有ECDSA with P-256、ECDSA with P-384 和 ECDSA with P-521等。

（4）JWT的校验

Header 和 Payload可以直接利用Base64 URL解码出原文。从Header中获取哈希签名的算法，从Payload中获取有效数据。Signature使用了不可逆的加密算法，无法解码出原文，它的作用是校验Token有没有被篡改。服务端用Header、Payload、SecretKey通过Header中的签名算法进行再次加密，比对加密后的数据和客户端发送过来Token中的的是否一致。

无论改了头部、负载、和签名中的哪个部分，Token校验都不会通过。由于缺乏安全性，也不应该将敏感的会话数据存储在浏览器存储中。

9.3 JWT的类型

JWT根据Payload部分是否加密，主要可以分为以下三种类型：

nonsecure JWT：未经过签名，不安全的JWT，Header部分没有指定签名算法，并且也没有Signature部分；
JWS：也就是JWT Signature，经过签名的JWT ，其结构就是在之前nonsecure JWT的基础上，在头部声明签名算法，并在最后添加上签名；
JWE：Payload部分经过加密的JWT。

9.4 JWT的优缺点

😎 9.4.1 优点

优点总结：JWT 具有安全、可扩展、移动、简单和无状态等特点，因此它在分布式环境中广泛使用，例如基于 RESTful API 架构的网站和移动应用程序。
优点展开：
- 轻量级，解析方便：JWT基于JSON实现，是一个轻量级的身份验证和授权方案，因为它以JSON格式对数据进行传输，并且不需要在服务端进行存储。，而且非常方便解析。
- 易扩展，可扩展性好：因为 JWT 是面向 JSON 的，所以它非常灵活，并且易于与现有应用程序整合。除了包含标识信息外，JWT 还可以包含其他元数据，可以在令牌中自定义丰富的内容。
- 安全性高：JWT可通过非对称加密算法及数字签名技术来隐藏真实数据。通过使用签名来保护数据完整性，确保只有授权用户才能访问受保护的资源。
- 无状态，对服务端压力小：由于JWT将用户信息加密到Token里面，服务器不保存任何用户信息，不需要在服务器端存储会话状态信息，从而实现了无状态的请求处理，可以减轻服务器负担，占用带宽比较小。同时，由于JWT自身包含用户信息且无法篡改，在服务（网关）中可以自行解析校验出用户信息，对认证服务器（account-svc）压力小。
- 跨域支持，可移植性好：由于JWT使用的是标准的HTTP协议，因此支持跨域请求和移动端请求。由于 JWT 是基于网络的，因此它可以在不同的平台和系统之间轻松流通，并使分布式环境中的身份验证过程变得更加容易和安全。
- 跨语言适用：JWT已经得到了广泛的应用和支持，可以在不同的编程语言、框架和平台之间交换数据。

🤢 9.4.2 缺点

缺点总结：JWT 存在信息过载、安全性依赖密钥、无法禁用和撤回及，无状态及后端无法直接统计使用情况等缺点。虽然 JWT 在许多情况下都很方便，但作为安全机制的缺陷还是存在一些风险。所以JWT一般为了进一步提高安全性页会采用一些措施，比如传输时采用HTTPS等。
缺点展开：
- 无法修改，可被使用：JWT 生成之后无法修改而且JWT是无状态的，如果别人获取到了，别人也能用。
- 信息过载：JWT 中的所有信息都被编码为字符串并存储在一个 JSON 对象中，一旦存储的信息量过大，那么 JWT 的长度也会随之增加。令牌长度与其包含用户信息多少正相关，这可能会导致网络传输和存储的开销不断增加，降低系统性能。
- 安全性依赖密钥：JWT 通过密钥进行数字签名或加密来保证安全性，因此任何人掌握了密钥就能够伪造正确的 JWT，进而篡改和冒充其他用户的身份。因此，在分发、管理和保护密钥方面需要非常谨慎和严格。
- 无法禁用和撤回：由于 JWT 只能由密钥验证其有效性，并将所需的用户信息存储在其中，因此如果想要禁用或撤回某一个 JWT，只能够等到它失效或过期才能够完成。这意味着在遇到令牌被盗用或泄露的情况下，用户会处于高度风险状态。
- 后端无法直接统计：JWT 是一种无状态的身份验证机制，因此后端通常无法直接统计 JWT 的使用情况。然而，虽然后端无法直接统计 JWT 的使用情况，但是可以采取一些间接的方法来监控 JWT 的使用情况。例如：前端埋点、记录日志、使用第三方工具等。

9.5 JWT的应用及使用

9.5.1 JWT的两大应用

JWT主要应用在两个方面，一个是鉴权，另外一个是信息交换。有效地使用JWT可以减少服务器查询数据库的次数。

Authentication（鉴权）：JWT也是我们常见的授权登录方案。当使用JWT登录鉴权，则一旦用户登录，每个后继的请求都包含HWT，从而允许用户访问该令牌允许的路由，服务和资源。由于JWT的轻量性及跨域性，JWT也被广泛地应用在单点登录等场景中。
Information Exchange（信息交换） ：除了经典的登录鉴权，JWT也跟Token一样，可用于信息交换。JWT可以在各通信方间安全传输信息，而且根据前面的描述，JWT中可以包含自定义数据，借助自定义数据我们也可以传输一些非默认字段的数据。

9.5.2 JWT的使用场景

那根据前面对JWT两大应用方向的描述，JWT有哪些具体的使用场景呢？

单点登录（Single Sign-On，SSO）：JWT可以适用于分布式的单点登录场景，可用于实现SSO，使用户只需登录一次，就可以在多个应用程序或网站中访问受保护的资源。
无状态认证：传统的基于会话（session）的身份验证需要在服务器上维护会话状态，而JWT是一种无状态的认证机制，完全由客户端持有，不需要在服务器端存储任何信息，因此可以轻松地将认证信息传递给多个服务端。
安全的跨域数据传输：JWT可以使用跨域认证解决方案，而且可以通过在令牌里加入签名，来保证数据在传输过程中不被篡改和窃取。
基于角色的访问控制：JWT可以编码包含用户角色等信息的声明（Claim），从而方便根据用户角色控制对资源的访问权限。
前端分离项目、移动应用程序开发（移动app、小程序、H5）：由于移动应用程序通常没有基于会话的身份验证的概念，所以可以使用 JWT 来进行安全身份验证。

虽然相比于传统的Token，JWT具有无状态及安全性高等优点，但JWT并不适用于所有的应用场景，如果需要频繁更改权限、需要回收某些权限、需要撤销访问令牌等情况下，则使用JWT就不适合了。

9.5.3 JWT的使用方式

客户端收到服务器返回的 JWT，跟上一章提到的Token一样，可以选择存储在Cookie中，也可以选择存储在localStorage等。相关的局限性也在上一章中讲了，这里就不再重复了。

当客户端于服务端进行通信时，一般我们时将JWT放在HTTP请求头中的Authorization字段，这样子不仅可以提高安全性也可以实现跨域，比如：

Authorization: Bearer <token>

这里相关的知识点在上一章中也都一样，这里同样不做冗余介绍了。

除了上面将JWT放在Authorization字段中实现跨域，还可以在跨域时将其放在POST请求的数据体里面。

9.6 JWT的认证流程

在这里插入图片描述 1、用户登录，发送数据：首先，用户登录，通过表单提交等方式向服务端发送用户名和密码。这个数据发送请求一般时POST格式。为了进一步提高安全性可采用HTTPS协议进行传输，一般时通过SSL加密的HTTPS进行传输，从而避免敏感信息被嗅探。
2、服务端验证信息，返回生成的JWT：服务端核对用户名和密码成功后，将包含用户信息的数据作为JWT的Payload，将其与JWT Header分别进行Base64编码拼接后签名，形成一个JWT Token，并将其返回给客户端。
3、客户端收到返回的JWT并保存：客户端收到JWT后，将其保存在客户端本地的存储（比如localStorage或SessionStorage）中。
4、客户端后继请求携带JWT：客户端在后继的每次请求时，都要在HTTP请求头中的Authorization属性中携带JWT（可以解决XSS和XSRF问题）。
5、服务端验证JWT有效性：服务端检查客户端传过来的JWT Token，验证其有效性，比如检查签名是否正确、是否过期、Token的接收方是否是自己等等。
6、服务端解码JWT：验证通过后，服务端解析出JWT Token中包含的用户信息，进行其他逻辑操作(一般是根据用户信息得到权限等)，返回结果。

9.7 JWT常见的相关问题

（1）Base64 是可逆的，那JWT 安全吗?

Base64编码方式是可逆的，也就是透过编码后发放的Token内容是可以被解析的。一般而言，我们都不建议在有效载荷内放敏感讯息，比如使用者的密码。

（2）JWT Payload 內容可以被伪造吗？

JWT中的签名Signature可以防止通过Base64可逆方法回推有效载荷内容并将其修改。因为Signature是经由Header跟Payload一起Base64组成的。

（3）JWT空间及长度问题？

JWT Token通常长度不会太小，特别是Stateless JWT Token，把所有的数据都编在Token里，很快的就会超过Cookie的大小（4K）或者是URL长度限制。

（4）JWT失效问题？

无状态JWT令牌（Stateless JWT Token）发放出去之后，不能通过服务器端让令牌失效，必须等到过期时间过才会失去效用。
假设在这之间Token被拦截，或者有权限管理身份的差异造成授权Scope修改，都不能阻止发出去的Token失效并要求使用者重新请求新的Token。

JWT使用建议

不要存放敏感信息在Token里。
Payload中的 exp 时效不要设定太长。
开启 OnlyHttp 预防XSS攻击。
如果担心重播攻击（replay attacks ）可以增加 jti （JWT ID）， exp （有效时间） Claim
在应用程序应用层中增加黑名单机制，必要的时候可以进行Block做阻挡（这是针对掉令牌被第三方使用窃取的手动防御）

10. 拓展——安全

10.1 加密算法

前面我们也介绍了相关的加密算法，如果想要继续理解可以在后面看一下下面这篇笔记（因为合在一起会使这里的篇幅太长，所以我把它单独拎出来了）：
【前端知识】常见的加密算法介绍
前端中常见的加密算法主要形式包括——哈希函数，消息认证码，对称加密和非对称加密算法：
在这里插入图片描述

10.2 两种网络攻击

跟上面一样的道理，笔者我也将这部分相关的笔记单独拎出来了：
【前端知识】浅谈XSS和CSRF网络攻击
在这里插入图片描述这里为了方便，我就只放上XSS和CSRF的概念，其他更多的细节可以看上述的笔记：

CSRF攻击：CSRF（Cross Site Request Forgery，跨站域请求伪造），也被称为 “One Click Attack” 或者 Session Riding，通常缩写为 CSRF 或者 XSRF，是一种对网站的恶意利用。通常情况下，CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。
- CSRF攻击的防御：
XSS攻击：指攻击者通过利用网页开发时留下的漏洞，通过在网站上注入恶意指令代码，一般是指在HTML文件或者DOM中注入，使用户在浏览网页时不自觉的加载并执行攻击者恶意制造的网页程序，从而实现网页的篡改和用户隐私数据（比如Cookie、SessionID等）的窃取。

10.3 CSRF与XSS攻击

CSRF攻击的防御方法：
XSS攻击的防御方法：

11. 总结

11.1 三种机制与网络攻击/安全的关系

前面讲到安全相关的知识，所以从Cookie到Token，我们也知道他们的安全系数也在逐渐的增强，那它们与前面提到的网络攻击有什么关系，存在怎么样程度的安全风险呢？

11.1.1 Cookie

🎯 Cookie与CSRF攻击的关系
因为Cookie在浏览器发出任何请求中都会被自动携带同时发送，包括跨站请求。所以攻击者可以很容易利用Cookie的这个属性来伪造一个跨站请求，然后诱导用户在已经登录目标网站的情况下，执行该跨站请求，从而利用用户的Cookie实现用户信息的窃取。因此，Cookie很容易受到CSRF攻击。
一般来说，普通的CSRF攻击只是利用了用户的Cookie来盗用信息。需要注意的是，CSRF攻击者并不能直接读取或者修改到受害者的 Cookie 内容，而是拿着受害者提交的完整报文（包括 Cookie）去攻击目标网站。
🎯 Cookie如何应对CSRF攻击？
1. 为了防范 CSRF 攻击，可以使用过期时间短、HttpOnly、Secure、SameSite、StateSite等属性来增加 Cookie 的安全性。 其中，HttpOnly、Secure、SameSite 和 StateSite 都是 Cookie 中用于增强 Cookie 的安全性和保护用户隐私：
  - HttpOnly 属性可以来限制客户端 JavaScript 对 Cookie 的访问。
  - Secure 属性告诉浏览器仅在通过 HTTPS 访问网站时发送该 Cookie。当设置了 Secure 属性的 Cookie，则只能在安全的 HTTPS 连接中传输，而无法被非 HTTPS 传输协议所使用（如普通的 HTTP 协议），从而可以大幅度降低 Cookie 被窃听、篡改和伪造的风险。
  - SameSite属性用于防止 CSRF 攻击和用户隐私泄露。该属性有两种取值：Strict 和 Lax。
    - Strict：在同站点情况下，不管是否携带认证凭证，浏览器都禁止跨站点访问，即完全禁止第三方请求。
    - Lax：在跨站点 GET 请求时传递 Cookie，但在 POST、PUT、DELETE 或其他方法请求时则不会。这样，可以兼顾 CSRF 攻击和用户体验的安全问题。
  - StateSite属性整合了 Secure 和 SameSite 两个属性的特点，并提供更细粒度的配置方式。它有以下取值：
    - Strict：只支持 HTTPS 网站，并且完全禁止第三方 Cookie。
    - Lax：允许跨站点 GET 请求携带 Cookie，但不允许POST 等其他方法。
    - None：元素都不限制。
2. 在编码和设计时，可以采用 Token、服务端Referer 校验、双重 Cookie 验证、Ajax等方法来加强验证机制，以防止 CSRF 攻击的发生。
  - 服务端Referer 校验：Referer 是 HTTP 请求头部信息中的一个字段，记录了当前请求者来源页面的访问路径。在服务端进行 Referer 校验时，系统会检查请求头中 Referer 字段中网址的来源是否符合条件，若符合则视为有效请求，否则请求被视为异常操作予以拒绝。
  - 双重 Cookie 验证：双重 Cookie 验证适用于已登录用户的操作场景下，在表单或请求参数中添加一个存储在 Cookie 中的随机令牌，同时服务器认证该随机值是否与当前用户相关联，从而验证用户权限并防止 CSRF 攻击。
  - Token（在11.1.3节中介绍）
  - Ajax跨域请求：Ajax跨域请求不会自动携带cookie，源自浏览器的ajax同源策略，要想ajax自动携带cookie，需要在服务端进行配置。
🎯 Cookie与XSS攻击的关系
XSS可能会偷取Cookie信息，进而拿到用户的登录态进行模拟登录，并可修改Cookie。XSS 攻击者往往会利用网站漏洞插入恶意脚本代码（如跨站脚本攻击），从而在用户访问时执行该恶意代码，在用户浏览器中注入恶意请求，通过获取用户的 Cookie 状态信息以达到窃取或篡改 Cookie 的目的。例如：攻击者可以在评论区域写入一段JS代码，如果用户点击这个评论超链接，就可能导致用户的Cookie被盗取。
🎯 Cookie如何应对XSS攻击？
1. 为了防范 XSS 攻击，可以使用HttpOnly属性来增加 Cookie 的安全性。 HttpOnly 是很好的防御 XSS 攻击的工具之一，它可以从客户端禁止 JavaScript 访问特定的 Cookie，使Cookie不会被JS盗取，从而确保用户的隐私和安全。
2. 使用正则校验：XSS攻击的一个主要攻击途径就是通过表单提交来注入服务端的数据库。所以，在前端中，我们可以对表单数据进行正则验证，通过验证之后，才能提交数据。而在服务端，也应该对接收的数据进行规则校验，不符合规则的数据不应该入库。从接口层面，保证数据安全。
3. 进行数据转义：如果无法保证数据库的数据都是安全的，前端可以把所有需要展示到页面的数据，进行转义，比如遇到script标签，直接replace处理。或者遇到标签标识‘<’以及‘>’这类特殊字符，添加‘\’进行处理。
4. 加签名防止篡改：为了提高 Cookie 安全性，可以使用加密算法对 Cookie 进行加密处理，攻击者获取到 Cookie 后解密相对困难，从而保护用户敏感信息不被盗取。但需要注意的是，在使用加密算法时，也要确保算法的安全性和可靠性。

11.1.2 Session

🎯 Session与CSRF攻击/XSS攻击的关系
和Cookie一样容易受到CSRF攻击，也可能受到XSS攻击。因为Session ID 存储在Cookie中，Cookie容易被CSRF攻击所截取利用，因此存储在其中的Session ID也容易被CSRF攻击者利用伪造。
🎯 Session如何应对CSRF攻击/XSS攻击？
防御方法跟Cookie的大差不差，这里就不再赘述了。

11.1.3 Token

🎯 Token与CSRF攻击的关系
Token比Cookie和Session更安全，并且不容易受到CSRF攻击。CSRF（跨域请求伪造）的攻击特点是需要用户自己点击恶意网站的隐藏HTTP请求链接，这个发出去的HTTP请求会自动的携带上用户的Cookie信息给服务器，于是完成了请求伪造攻击。而Token因为是自定义字符串，所以HTTP请求不会自动携带它，CSRF也就无法得手了（即使用户点击了恶意网站的请求也无法被拿走Token），之所以说Token天然防CSRF，但也不是绝对的，前提是不把Token存储到浏览器的Cookie里。
🎯 Token与XSS攻击的关系
如果Token是存储在浏览器的localstorage或sessionstorage中，则可能会受到XSS攻击。这是因为，通过恶意脚本，攻击者可以直接从浏览器存储中访问Token的值。

11.2 从Cookie到JWT的发展总结

虽然从Cookie到JWT都是用于标识客户端的，但从发展上来看可以看成网络安全的一个发展吧。

首先，Cookie由服务器创建的，只保存在浏览器中的小型文本文件，一般包含用户信息，登录及访问权限等。
考虑到Cookie保存在客户端被窃取的风险较大，Session机制把服务器与浏览器的会话信息（验证信息）临时的保存在服务器上，并利用Session ID 进行客户端的识别。这样子，用户就没有权限操作服务器，可以避免非法用户窃取Session中的数据，从而保证数据的安全性。
虽然Session把用户状态和行为信息放在服务器上，可以提高一定的安全性，但Session ID保存在Cookie中，也有被窃取的可能，跟Cookie一样，Session也会受到CSRF的攻击，而且Session请求的体积比较大，也会增加服务器的成本（需要考虑分布式和服务器负载均衡的问题）。因此，Token机制采用打包加证件的方式来保证安全和信息的轻量化。
也就是Token机制将信息打包到Cookie中，这种样子可以减少服务器压力，同时Token自己作为访问资源的凭证（客户端唯一的标识），可以用于身份验证和授权。有点类似Cookie，但更加安全，Token是服务器将验证后的登陆凭证做数字签名，加密之后得到的字符串。
JWT的出现改善了传统Token需要查库验证用户信息，而JWT不用查库或者少查库，直接在服务端进行校验，并且不用查库。因为用户的信息及加密信息在第二部分payload和第三部分签证中已经生成，只要在服务端进行校验就行，并且校验也是JWT自己实现的。

11.3 从Cookie到JWT的区别总结

Cookie:保存在浏览器中，有大小限制，有状态
Session：保存在服务器中，服务器有资源开销，分布式、跨系统不好实现
Token：客户端可以将token保存到任何地方，无限制，无状态，利于分布式部署

形式不同：Cookie是小型文本文件，Session是用户状态列表，Token/JWT是字符串。
存储位置不同：Cookie、Token/JWT 存储在客户端；而Session 存储在服务端。
存储核心内容不同：Cookie 通常表示用户标识信息、会话状态或其余业务相关信息；Session 存储敏感数据（比如用户的密码等）；而 Token/JWT 表示会话安全令牌。
安全性不同：Cookie 可能面临 CSRF/ XSS 等风险；Session 更加地安全，不过由于 Session ID 可以猜测到，容易被伪造导致 Session 端口扫描等攻击；Token/JWT 则采用了数字签名或其他方式保证了数据的完整性和安全性，应用相对更加安全。
可跨域性不同：通过设置 domain 和 path 属性，Cookie 能够使用户在不同域名和路径间共享信息；Session 只能实现子域名间的数据共享，而 Token/JWT 不需要考虑域名、路径问题。
占用空间不同：
- Cookie 只适合小型的数据（单个Cookie通常最多支持4KB的数据存储），无法存储大量数据。
- Session 可以存储更多，但给服务器造成压力。Session没有严格的限制，可以存储的数据量相对较大，但是与服务器内存大小有关。虽然Session 的体积大小并没有明确的限制，但是在实际应用中一般也不会超过几KB。
- 而 Token/JWT 是一种轻便且高效的方案，Token的大小不同取决于使用的加密算法和使用的Token格式。相对于Cookie和Session，Token一般比较轻量级，通常只需要几十个字节。
- Cookie 通常适用于轻量级数据；Session 更适合小型、散乱位置的内容；而 Token/JWT 适用于处理分布式系统等较复杂的情形。
支持数据类型不同：
- Cookie 可以存储任何字符串类型的值（例如文本、数字、日期等），但是大小受到限制，一般不超过4KB。
- 和 Cookie 类似，Session 也可以存储各种字符串类型的值，包括文本、数字、日期等。但是，与 Cookie 不同的是，Session 还可以存储复杂的对象类型（例如数组、哈希表、类实例等），这些类型的数据独立于应用程序之外，并在每个会话生命周期内保存。
- Token 可以存储任何类型的数据，也可以存储复杂的 JSON 对象或者序列化后的二进制数据等类型。但是，建议只存储必要的信息，并避免存储敏感数据，从而保证安全性。
有效期不同，默认生命周期不同：
- Cookie 默认生命周期为会话级别，也就是说，当用户关闭浏览器或在一定时间段内没有活动时，Cookie 将自动失效。如果需要设置 Cookie 的有效期，则需要在服务器端设置相应参数，比如 Expires，当 Expires 时间到达时，服务器会将该 Cookie 删除或重新设置。一般来说，Cookie 的有效期比较短。如果未设置过期时间，那么Cookie在关闭浏览器时就会被删除。
- Session ID 的过期时间由 Web 服务器配置来决定，通常默认为为30分钟，也有20分钟到24小时不等的。在服务端，Session 的生命周期决定于服务器的配置和超时规则。如果服务器未设置 Session 过期时间，那么 Session 将一直存在，直到服务器被关闭或者手动结束。
- 默认情况下，Token使用期限是永久的，只有服务器才能终止该Token。但Token 的有效期可由开发者自行设置。JWT 则需要在 Token 中包含过期时间，并且服务器会对 Token 的有效性进行检查，如果过期，则需要重新获取 Token。如果 Token 未设置有效期，它将永远有效，这可能导致安全问题。
主要应用场景不同：见11.4

11.4 从Cookie到JWT的应用总结

总结：Cookie通常用于用户的浏览器行为跟踪和个性化设置等方面，Session更多地是进行一些会话管理与服务，Token和JWT则更多的是用于身份认证，在跨域下进行身份认证和授权。其中,
JWT更加适合在单页应用程序或分布式系统。Cookie
展开：
- Cookie应用场景
  - 通过在客户端存储数据（如用户 ID 和一些设置），允许服务器跟踪认证状态。Cookie 适合在需要持续跟踪会话状态时使用，例如购物车或社交媒体网站，还可以根据对浏览器行为跟踪分析用户行为，进行个性化的设置及推荐。
  - 之前总结果的常用场景：（1）登录状态及用户信息的管理；（2）跟踪用户行为，统计分析，广告定位；（3）记住用户偏好设置，定制页面；（4）创建购物车；（5）缓存数据，用于搜索历史和浏览记录；（6）跨页面数据传递，实现数据共享与同步 …
- Session应用场景
  - 会话适合在需要高度安全性和可靠性的应用程序中使用，例如在线银行或金融服务。对于简单而且不敏感的数据通常使用Cookie保存，如购物车信息、用户在站点的行为记录等；而对于复杂且敏感的数据使用Session保存，如用户的账号信息等。
  - 之前总结果的常用场景：（1）登录状态及用户信息的管理；（2）跟踪用户行为，统计分析，个性化推荐；（3）实现数据共享，多步骤操作；（4）网站安全；（5）处理后台任务；（6）消息提醒及表单数据存储等 …
- Token应用场景
  - 包含有关特定用户身份验证的信息，可以防止 CSRF 攻击。通常，Token 是 JSON 对象，可以在 Web 应用程序之间进行传输，并在本地存储。Token 适合在需要反复跨越多个域进行身份验证和授权时使用，例如REST API或移动应用程序。
  - 之前总结果的常用场景：（1）身份认证和授权控制；（2）可以作为支付方式，进行数字货币和加密货币交易；（3）可以作为奖励和积分；（4）安全性口令；（5）门禁控制；（6）辅助追溯，进行审查和监视 …
- JWT应用场景
  - 与Token 类似，但它是一种开放的标准（由 IETF 组织制定），使用 JSON 对象包含有关用户身份验证的信息，并被数字签名以确保其完整性。JWT 适合在需要可扩展性和安全性的 Web 应用程序中使用，例如单点登录、单页应用程序、前后端分离项目或分布式系统。
  - 之前总结果的常用场景：（1）登录鉴权；（2）信息交换 …

12. 其他

码字不易，可能当中存在某些字体错误（笔者我没有发现），如果有错误，欢迎大家指正。🤗

xiaobai_Ry

关注

6
点赞
踩
3

收藏

觉得还不错? 一键收藏
打赏
0
评论
【前端知识】Cookie, Session,Token和JWT的发展及区别（四）

最通俗的关于Cookie, Session，Token和JWT的相关笔记和理解。在终章笔记中主要介绍一下JWT以及总结Cookie到JWT的区别与发展，包括JWT的定义，特点，重要属性，优缺点，作用和使用场景，Cookie到JWT场景，安全等的区别。上章：主要介绍背景和Cookie中章：主要介绍一下Session并总结一下Cookie和Session。下章：主要介绍Token的相关定义及理解。终章：主要介绍JWT并总结JWT和Token的区别，以及总结Cookie到JWT的区别。
复制链接

扫一扫