Cookie、Session、Token详细介绍

🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀
通过这么长时间的学习，对客户端和服务器进行交互的三个重要方式做出总结，一起学习，如有疏漏或者错误，望批评指正！！！
😍 🥰 😘 😗 😙 😚 😋 😛 😝 😜 🤪 🤨 🧐 🤓 😎 🤩 🥳🙂 🙃 😉🤗 🤔 🤭😃 😄 😁 😆

一、Cookie

1、什么是Cookie[饼干]

首先我们要明确，HTTP（Hypertext Transfer Protocol）是一种无状态的协议。这意味着每个HTTP请求都是独立的，服务器不会存储关于客户端（浏览器）的任何信息。当客户端发送请求时，服务器仅处理该请求并发送响应，然后立即忘记该请求。下一次请求来自同一客户端时，服务器无法知道前面的请求或与之相关的任何状态信息。

为了处理有状态的需求，引入了一些机制，如Cookie和会话（Session）。使用这些机制，服务器可以在客户端和服务器之间传递数据，以维护会话状态。Cookie是一种在客户端存储数据的机制，而会话是一种在服务器端存储数据的机制。通过将会话标识符存储在Cookie中或通过URL重写等方式将其传递，服务器可以识别客户端并恢复相关的状态信息。

• Cookie存储在客户端:Cookie是一种在客户端（通常是Web浏览器）存储数据的机制，由服务器发送给浏览器，并在浏览器的Cookie存储中保存。它通常用于在无状态的HTTP协议中跟踪和维护用户会话状态。Cookie可以存储在浏览器的内存中（会话Cookie），也可以存储在用户的硬盘上（持久Cookie）。
• 携带Cookie进行访问:当用户访问一个网站时，服务器可以通过在HTTP响应中包含Set-Cookie头来发送一个或多个Cookie给浏览器。浏览器会将这些Cookie存储起来，并在随后的请求中自动将它们包含在Cookie头中发送回服务器。服务器可以根据这些Cookie来识别用户、维护用户状态和提供个性化的功能。
• Cookie是不可跨域的:每个Cookie都是和单一的域名进行绑定，在其他的域名下是没有办法进行使用的，但是一级域名和二级域名之间是能够共享使用的，这种共享Cookie的设置需要通过合适的域名配置和相应的浏览器支持，以确保Cookie在不同的子域名之间共享。

2、Cookie的属性组成

属性	说明
name=value	键值对，设置 Cookie 的名称及相对应的值，都必须是字符串类型 - 如果值为 Unicode 字符，需要为字符编码。 - 如果值为二进制数据，则需要使用 BASE64 编码。
domain	指定 cookie 所属域名，默认是当前域名
path	指定 cookie 在哪个路径（路由）下生效，默认是 ‘/’。 如果设置为 /abc，则只有 /abc 下的路由可以访问到该 cookie，如：/abc/read。
maxAge	cookie 失效的时间，单位秒。如果为整数，则该 cookie 在 maxAge 秒后失效。如果为负数，该 cookie 为临时 cookie ，关闭浏览器即失效，浏览器也不会以任何形式保存该 cookie 。如果为 0，表示删除该 cookie 。默认为 -1。 - 比 expires 好用。
expires	过期时间，在设置的某个时间点后该 cookie 就会失效。 一般浏览器的 cookie 都是默认储存的，当关闭浏览器结束这个会话的时候，这个 cookie 也就会被删除
secure	该 cookie 是否仅被使用安全协议传输。安全协议有 HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false。 当 secure 值为 true 时，cookie 在 HTTP 中是无效，在 HTTPS 中才有效。
httpOnly	如果给某个 cookie 设置了 httpOnly 属性，则无法通过 JS 脚本 读取到该 cookie 的信息，但还是能通过 Application 中手动修改 cookie，所以只是在一定程度上可以防止 XSS 攻击，不是绝对的安全

3、Cookie在浏览器的传输

• 我们在发送HTTP请求时，发现游览器将我们的cookie都进行了携带(注意：游览器只会携带在当前请求的url中包含了该cookie中path值的cookie)，并且是以key：value的形式进行表示的。多个cookie用；进行隔开。
• Cookie就是一些数据，用于存储服务器返回给客服端的信息，客户端进行保存。在下一次访问该网站时，客户端会将保存的cookie一同发给服务器，服务器再利用cookie进行一些操作。利用cookie我们就可以实现自动登录，保存游览历史，身份验证等功能。

小案例：

你怎么证明你是学校的学生？

你 ---- 学校

1. 发票 学校给你开发票
2. 学校登记 学校标记你过来了

一个网站，怎么证明你来过？

客户端 ----- 服务器

1. 服务端给客户端一个 信件，客户端下次访问服务端带上信件就可以；cookie
2. 服务器登记你过来了，下次你来的时候我来匹配你。session

二、Session

Session也称会话，基于Cookie实现，是另外一种记录服务器和客户端会话状态的机制

1、什么是Session

• Session是一种在网络通信中用于跟踪用户状态的机制。在Web应用程序中，服务器使用Session来存储和管理与特定用户相关的信息，以便在用户的连续请求之间保持状态。
• 当用户访问一个使用Session的网站时，服务器会为该用户创建一个唯一的Session ID，并将这个ID与用户的会话相关联。这个Session ID通常会被存储在Cookie中，以便在用户的每个请求中发送给服务器。服务器根据Session ID来查找相应的会话数据，以便为每个用户提供个性化的服务和保持用户状态。

2、Session的作用

• 状态管理：Session允许服务器在用户请求之间跟踪和管理用户的状态。通过Session，服务器可以存储和检索与特定用户相关的信息，如登录状态、购物车内容、用户首选项等。这样，在用户的不同请求之间，服务器可以获取并维持用户的状态，提供一致性和个性化的体验。
• 用户身份验证：Session常用于用户身份验证。当用户通过用户名和密码登录后，服务器会创建一个Session并将登录状态相关的信息存储在Session中。随后，服务器可以根据Session验证用户的身份，而不需要用户每次请求都重新登录。
• 数据共享：通过Session，服务器可以在不同的页面和请求之间共享数据。服务器可以将数据存储在Session中，然后在用户的不同请求中进行访问和修改。这对于在应用程序中共享数据、传递数据或在多个页面之间共享上下文非常有用。

3、session 认证流程：

1. 用户访问网站并提供登录凭据（用户名和密码）。
2. 第一次登录请求，服务器验证用户提供的凭据是否正确。如果凭据有效，服务器创建一个唯一的Session ID。
3. 服务器将用户的身份信息和其他相关数据存储在服务器端的Session存储中，通常是在内存或数据库中。
4. 服务器将Session ID发送给客户端，通常是通过将Session ID存储在Cookie中，并在响应中返回给客户端。
5. 客户端的浏览器接收到响应，并存储Session ID的Cookie。
6. 在用户的后续请求中，浏览器会自动将存储的Cookie中的Session ID发送给服务器。
7. 服务器接收到带有Session ID的请求，通过该ID找到对应的Session数据。
8. 服务器验证Session ID的有效性，并根据Session数据判断用户的身份和权限。
9. 根据用户的身份和权限，服务器处理请求并返回相应的内容。
10. 用户继续进行其他操作，每次请求都包含相同的Session ID。
11. 当用户退出登录或会话过期时，服务器会销毁相关的Session数据，使Session失效。
12. 如果用户再次访问网站，需要重新进行认证，重复上述步骤。

4、Cookie和Session的不同

SessionID是重要的组成部分，它将Cookie和Seesion连接到一起，共同参与客户端和服务器的通信，验证登录状态

1. 存储位置：Cookie是存储在客户端（浏览器）中的小型文本文件，而Session数据存储在服务器端。
2. 数据容量：Cookie的数据容量较小，通常限制在几KB，而Session可以存储更大量的数据，因为它存储在服务器上。
3. 安全性：由于Cookie存储在客户端，它们可能会受到一些安全风险，如被窃取或篡改。为了增加安全性，可以对Cookie进行加密或使用安全标志，如Secure和HttpOnly。相比之下，Session数据存储在服务器端，更难以被窃取，但仍然需要注意服务器的安全性。
4. 生命周期：Cookie可以设置不同的过期时间，可以是会话级别的（关闭浏览器时过期）或具有固定的过期日期。而Session通常在用户关闭浏览器或超过一定时间不活动时过期，也可以由开发人员手动设置过期时间。
5. 性能开销：由于Session数据存储在服务器上，每个用户的Session都需要占用服务器资源。相比之下，Cookie的存储和传输对服务器的负担较小。

三、Token

1、什么是Token

Token是在计算机科学和网络安全中使用的一种令牌机制，用于验证身份和授权访问。

在身份验证方面，Token通常指的是身份验证令牌，它是一个表示用户身份的字符串或数据结构。当用户进行身份验证时，系统会颁发一个Token给用户。该Token可以包含有关用户身份的信息，例如用户ID、角色、权限等。用户在后续请求中使用Token来证明自己的身份，而不需要再次提供用户名和密码。常见的身份验证Token包括JSON Web Token（JWT）和OAuth2授权令牌。

在授权访问方面，Token用于验证客户端的授权权限，以获取对特定资源或服务的访问权限。当客户端请求访问受保护的资源时，它需要提供有效的Token来证明自己有权访问该资源。服务器会验证Token的有效性和权限，并根据结果决定是否允许客户端的访问。常见的授权访问Token包括OAuth2访问令牌和OpenID Connect身份令牌。

Token的常见组成：

Token的组成可以因使用的标准或实现方式而有所不同。以下是常见的Token组成部分：

• 头部（Header）：Token的头部通常是一个包含有关Token类型和加密算法的JSON对象。例如，JWT的头部可能包含"alg"表示使用的签名算法（如HMAC、RSA）和"typ"表示Token类型（如JWT）。

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

• 载荷（Payload）：Token的载荷是一个包含有关用户或其他实体的相关信息的JSON对象。它可以包含标准的声明（如用户ID、角色、权限等）和自定义的声明。Payload是Token中存储数据的主要部分。

  • 请注意，默认情况下JWT是未加密的，任何人都可以解读其内容，因此不要构建隐私信息字段，存放保密信息，以防止信息泄露。
    

• 签名（Signature）：签名是用于验证Token的完整性和真实性的部分。签名通常是使用私钥（对称加密）或公钥（非对称加密）对头部和载荷进行签名生成的。在验证Token时，接收方使用相应的密钥来验证签名是否有效，以确保Token未被篡改。

  • HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(claims), secret)    ==>   签名hash
    

这些部分通常以一定的方式进行编码和组合，以生成最终的Token字符串。不同的标准和实现可能在编码格式、分隔符、加密算法等方面有所差异。例如，JWT（JSON Web Token）使用Base64编码来表示头部和载荷，并使用点号（.）来分隔各个部分，形成最终的Token字符串。

总结起来，Token的组成通常包括头部、载荷和签名部分，每个部分都承载着不同的信息和功能。这种结构化的Token设计使得在验证和解析Token时更加方便和可靠。

2、Token的优点：

1. 无需在每个请求中传输用户名和密码，减少了敏感信息的传输风险。
2. 支持跨平台和跨域访问，使得不同系统之间的集成更加灵活。
3. 服务端无状态化、可扩展性好可以轻松地进行扩展和撤销，适应不同的业务需求。

需要注意的是，Token的安全性非常重要。在设计和实现Token机制时，需要采取适当的安全措施，如使用加密算法对Token进行签名和验证，限制Token的使用范围和有效期限，并进行适当的访问控制和权限管理。

3、Token的身份验证流程：

Token身份验证的流程可以概括为以下步骤：

1. 用户提供身份凭据：用户向身份验证系统提供身份凭据，通常是用户名和密码。这可以是登录表单、API请求或其他方式。

2. 身份验证请求：身份验证系统收到用户的身份凭据后，进行验证请求。这可能涉及与存储用户凭据的数据库或身份提供者进行比对验证。

3. 生成Token：如果用户的身份验证成功，身份验证系统会生成一个Token作为身份验证结果。Token可以是JSON Web Token（JWT）、OAuth2访问令牌或其他类型的令牌。

4. 发送Token给客户端：身份验证系统将生成的Token发送给客户端（如浏览器、移动应用程序等）。通常，Token会作为响应的一部分返回给客户端，可以放置在响应的头部、Cookie或响应体中。

5. 客户端存储Token：客户端接收到Token后，将其存储在安全的位置，例如本地存储[localStorage]、内存或Cookie中。

6. 后续请求中发送Token：客户端在后续的请求中，将Token作为身份验证凭据的一部分发送给服务器。这通常是通过在请求的头部（如Authorization头部）或查询参数中携带Token来实现。

7. 服务器验证Token：服务器在接收到带有Token的请求后，使用相应的密钥（对称或非对称）来验证Token的完整性和真实性。它会解析Token的内容，验证签名，并检查Token的有效期、权限等声明。

8. 验证结果返回：服务器根据Token的验证结果，决定是否允许用户访问请求的资源或执行特定操作。如果验证成功，服务器会响应请求并提供所需的数据或操作；如果验证失败，服务器会拒绝访问，并返回相应的错误响应。
   

• 每次请求都会携带token，把token放在Http请求的请求头里
• 服务端不用存放token数据，只需要解析验证从客户端带有Token的请求，用解析Token的计算时间换区session的存储空间，减轻了服务器的压力

四、Token 和 Session 的区别

Token和Session是用于在Web应用程序中进行身份验证和授权的两种不同的机制，它们之间有以下详细的区别：

1. 存储位置：

• Token：Token是存储在客户端（如浏览器、移动应用程序）中的，通常以Cookie或自定义的头部方式传递给服务器。
• Session：Session是存储在服务器端的数据结构，通常存储在服务器的内存或数据库中。

2. 数据存储方式：

• Token：Token中包含了用户的身份信息和其他必要的数据，通常使用一种标准的数据格式（如JSON Web Token）进行编码和解码。
• Session：Session中存储了用户的状态和相关数据，可以在服务器端进行读取和修改。

3. 存储容量：

• Token：Token的存储容量较小，因为它需要在每个请求中传递。通常只包含有关身份验证和授权的必要信息。
• Session：Session的存储容量较大，因为数据存储在服务器端，可以存储更多的用户状态和相关数据。

4. 安全性：

• Token：Token需要采取安全措施，如加密和签名，以确保其完整性和真实性。可以使用标准的加密算法和签名机制进行验证。
• Session：Session相对较安全，因为数据存储在服务器端，对客户端是不可见的。但需要保护好Session ID，以防止会话劫持等攻击。

5. 跨域支持：

• Token：Token可以在跨域之间共享，并且适用于跨平台和跨域的访问控制。
• Session：Session通常限制在单个域名或子域，不容易在跨域环境下进行共享。

6. 扩展性：

• Token：Token机制更具扩展性，适用于构建分布式系统和微服务架构，因为每个服务可以独立验证和授权Token。
• Session：Session机制通常用于单体应用程序，因为Session存储在服务器端，不容易在不同服务之间共享和验证。

7. 生命周期和状态管理：

• Token：Token通常有一个固定的有效期，可以设置长短不同的过期时间，由客户端管理和维护。
• Session：Session的生命周期由服务器管理，可以根据特定的策略（如过期时间、空闲时间等）来管理和维护。

• Session是一种记录服务器和客户端会话状态的机制，使服务器状态化。Token是令牌，就是客户端访问服务器资源的通行证，它使服务器无状态化，不存储会话信息和数据
• Token作为身份认证的安全性高于Session，每一个请求都有唯一签名并且能够防止监听；Session要依赖于链路层来保证客户端和服务器的会话安全。然而他们并不矛盾，都是在确保客户端和服务器的正常和安全通讯。在使用Token时，如果希望实现有状态，可以增加Session在服务器保存一些需要的状态。
• 通过Session进行用户认证就是把用户信息存储到Session中，得到唯一的SeesionID，由于SessionID是不确定的，可以认为是相对安全的。Token提供的是认证和授权，用户认证和应用授权，并且Token是唯一的，只能是本用户，也只能是本应用不能转接到其他应用。进行用户认证时Token通常有一个固定的有效期，可以设置长短不同的过期时间。用户可以在有效期内重复使用Token，而无需每次请求都进行身份验证；而Session的生命周期由服务器管理，可以根据配置设置过期时间或者空闲时间来控制Session的有效期。用户关闭浏览器或超过一定时间不活动时，Session通常会过期。

五、JWT

1、什么是JWT

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA

官方解释

官网地址:https://jwt.io/introduction/

翻译:JSON Web令牌（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各方之间作为JSON对象安全地传输信息。由于此信息是经过数字签名的，因此可以被验证和信任。可以使用秘密（使用HMAC算法）或使用RSA或ECDSA的公用/专用密钥对对JWT进行签名。

2、JWT作用

1.授权

这是使用JWT的最常见方案。一旦用户登录，每个后续请求将包括JWT,从而允许用户访问该令牌允许的路由，服务和资源。单点登录是今广泛使用JWT的一项功能。因为它的开销很小并且可以在不同的域中轻松使用

2.信息交换

JSON Web Token是在各方之间安全地传输信息的好方法。因为可以对JWT进行签名（例如，使用公钥/私钥对），所以您可以确保发件人是他们所说的人。此外，由于签名是使用标头和有效负载计算的，因此您还可以验证内容是否遭到篡改。

3、基于JWT认证

JWT（JSON Web Token）是一种用于认证和授权的开放标准，允许在网络应用程序之间安全地传输信息。它由三个部分组成：头部（Header）、载荷（Payload）和签名（Signature）。每个部分都是Base64编码的JSON字符串，并通过句点（.）进行分隔。这种结构使得JWT非常适合在客户端和服务器之间进行安全通信。

JWT的工作流程如下：

• 用户向服务器发送其认证凭证（例如用户名和密码）。
• 服务器验证用户的凭证，并生成一个包含用户信息和其他相关数据的JWT。
• 服务器将JWT返回给客户端。
• 客户端将JWT存储在本地（通常是在浏览器的本地存储或Cookie中）。
• 在后续请求中，客户端将JWT附加到请求头中，作为认证的凭证。
• 服务器接收请求并从JWT中提取认证信息，以验证用户的身份和权限。

JWT具有以下特点：

1. 自包含：载荷部分包含了用户的信息以及相关数据，无需进一步查询数据库。
2. 无状态：服务器不需要在后端存储任何关于用户会话的信息，因为JWT本身包含了所有必要的信息。
3. 安全：JWT使用签名来验证其完整性，防止篡改和伪造。
4. 可扩展：可以通过在载荷中添加自定义字段来扩展JWT的功能。
5. 跨平台：JWT可以在不同的编程语言和平台之间轻松交换和解析。

JWT的一个常见用例是在Web应用程序中用作身份验证（Authentication）和授权（Authorization）机制。在身份验证方面，JWT能够验证用户的身份，而在授权方面，它可以包含用户的角色和权限信息，使得服务器可以根据JWT的内容控制用户能够访问的资源和功能。

需要注意的是，JWT并不适合用于敏感信息的存储，因为虽然JWT的内容可以加密，但签名仍然是公开的，任何人都可以解码和查看JWT的内容。因此，敏感信息应该使用其他方式进行加密和处理。

4、常见的加密方法

1. 对称加密算法：

   • AES（Advanced Encryption Standard）：目前最广泛使用的对称加密算法之一，支持128位、192位和256位密钥长度。
   • DES（Data Encryption Standard）：早期的对称加密算法，使用56位密钥长度，现已被AES所取代。
   • 3DES（Triple Data Encryption Standard）：DES的加强版，通过多次DES算法的迭代来提高安全性。

2. 非对称加密算法：

   • RSA（Rivest-Shamir-Adleman）：最常用的非对称加密算法之一，基于数论的复杂性问题，用于数据加密和数字签名。
   • ECC（Elliptic Curve Cryptography）：基于椭圆曲线理论的非对称加密算法，提供与RSA相当的安全性，但使用更短的密钥长度，适用于资源受限的环境。

3. 散列函数（哈希函数）：

   • MD5（Message Digest Algorithm 5）：常用的散列函数之一，生成128位（16字节）哈希值，但因为存在安全性问题，已不推荐用于加密应用。
   • SHA（Secure Hash Algorithm）系列：SHA-1、SHA-256、SHA-384、SHA-512等，根据输出长度的不同，生成不同位数的哈希值，广泛用于密码校验、数据完整性验证等领域。
   • HMAC（Hash-based Message Authentication Code）：结合散列函数和密钥的算法，用于生成带有密钥认证的哈希值。

这些加密算法在不同的应用场景和需求中有不同的适用性。在选择加密算法时，需要考虑安全性、性能、资源消耗以及特定需求（如加密强度、密钥长度、支持性等）等因素。此外，随着技术的不断发展，加密算法也会不断演进和更新，以应对新的安全挑战。因此，建议在实际使用中参考最新的安全标准和推荐。

六、使用注意事项

1、🍪Cookie

1. 安全性：使用安全的传输协议（例如HTTPS）来加密Cookie的传输，防止中间人攻击；对敏感信息进行加密或使用加密的Cookie。使用前需要验证合法性，同时使用HttpOnly在一定程度上提高安全性。
2. 隐私保护：仅存储必要的信息，避免存储敏感个人信息，采用适当的数据保护措施，如数据加密或匿名化处理，向用户提供透明的隐私政策，明确说明使用Cookie的目的和方式，并提供相关的选择和控制权。
3. 跨域问题🍪cookie无法跨域
4. Cookie大小和数量：过多或过大的Cookie可能会增加网络传输的负担，并可能导致性能问题。尽量减少 cookie 的体积，能存储的数据量不能超过 4kb;一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie.
5. 使用范围:cookie主要在网页端使用

2、Session

1. 占用率高:因为Session存储在服务器里面，在有大量用户同时在线的的情况发生时，就会占用服务器的很多内存，服务器需要保证内存足够，所以要到期清理Session
2. 跨域问题：在跨域场景下，Session共享和传递可能面临限制。需要了解跨域策略，并采取适当的解决方案，如使用跨域资源共享（CORS）或代理等。
3. 关联Cookie问题:SessionID 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie 。 一般会把 SessionID 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现

3、Token

1. 安全性：Token作为身份验证凭证，使用安全的传输协议（如HTTPS）传递Token，以防止中间人攻击。对Token进行适当的加密或签名，确保其完整性和防止篡改。避免在请求参数或URL中明文传递Token，而是使用请求头或其他安全方式传递。
2. 防止Token泄露：：避免在不安全的环境中存储Token，如浏览器的本地存储或Cookie中。使用安全的存储方式，如HTTP-Only Cookie或安全的本地存储。设置适当的Token过期时间，定期刷新Token，并且在用户注销或超时时使Token失效。考虑使用单一用途的短期Token，以降低泄露风险。
3. 令牌管理：合适的生成算法和密钥长度来生成Token。使用黑名单或撤销机制来处理被盗用或不再需要的Token。考虑使用令牌刷新机制，避免频繁用户登录或Token失效导致的用户体验问题。
4. 缓存机制:可以使用Redis等非关系型数据库进行缓存处理，提高查询速度
5. 完全由应用管理，避免同源策略；同时移动端常用token

4、JWT

1. 安全性：JWT作为身份验证凭证，需要采取措施确保其安全性：
   • 使用安全的传输协议（如HTTPS）传递JWT，以防止中间人攻击。
   • 对JWT进行适当的签名（使用HMAC或RSA等算法），确保其完整性和防止篡改。
   • 选择安全的密钥管理和密钥长度，以防止密钥泄露和暴力破解。
2. 避免敏感信息：尽量避免将敏感个人信息直接存储在JWT中。JWT通常用于身份验证和授权，而不是用于存储大量用户信息。
3. 有效期管理：为JWT设置合理的过期时间，避免过长的有效期导致安全风险，同时避免频繁的JWT刷新操作影响性能。
4. 颁发和验证：确保JWT的颁发和验证过程安全可靠：
   • 在颁发JWT时，验证用户身份和权限，并使用安全的密钥签名JWT。
   • 在验证JWT时，验证JWT的签名、过期时间和其他声明，以确保JWT的有效性和合法性。
5. JWT的大小：JWT的大小会影响网络传输和存储开销，尽量避免在JWT中存储过多的数据。考虑使用较小的声明和选择合适的编码方式，如Base64URL编码。
6. 令牌撤销：如果需要撤销或失效某个JWT，需要建立相应的撤销机制。这可以是使用黑名单（如存储已撤销的JWT的数据库或缓存）或者使用短期的JWT，通过更频繁的刷新来实现。
7. 高负载环境下的性能：在高负载环境下，JWT的验证和处理可能会成为性能瓶颈。可以采取一些优化措施，如缓存已验证的JWT或使用无状态的验证方式（如使用JWK集合）。