Cookie、Session、Token、JWT详细介绍

ANnianStriver

已于 2023-07-02 16:56:26 修改

阅读量711

点赞数 1

分类专栏： JavaWeb 文章标签：服务器交互

于 2023-07-02 15:32:51 首次发布

本文链接：https://blog.csdn.net/AN_NI_112/article/details/131501391

版权

JavaWeb 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

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我们就可以实现自动登录，保存游览历史，身份验证等功能。

小案例：

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

你 ---- 学校

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

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

客户端 ----- 服务器

服务端给客户端一个信件，客户端下次访问服务端带上信件就可以；cookie
服务器登记你过来了，下次你来的时候我来匹配你。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 认证流程：

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

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-d08OmrpK-1688282648467)(E:\Typora\images\typora-user-images\image-20230702103537903.png)]$

4、Cookie和Session的不同

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

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

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

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

3、Token的身份验证流程：

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

用户提供身份凭据：用户向身份验证系统提供身份凭据，通常是用户名和密码。这可以是登录表单、API请求或其他方式。
身份验证请求：身份验证系统收到用户的身份凭据后，进行验证请求。这可能涉及与存储用户凭据的数据库或身份提供者进行比对验证。
生成Token：如果用户的身份验证成功，身份验证系统会生成一个Token作为身份验证结果。Token可以是JSON Web Token（JWT）、OAuth2访问令牌或其他类型的令牌。
发送Token给客户端：身份验证系统将生成的Token发送给客户端（如浏览器、移动应用程序等）。通常，Token会作为响应的一部分返回给客户端，可以放置在响应的头部、Cookie或响应体中。
客户端存储Token：客户端接收到Token后，将其存储在安全的位置，例如本地存储[localStorage]、内存或Cookie中。
后续请求中发送Token：客户端在后续的请求中，将Token作为身份验证凭据的一部分发送给服务器。这通常是通过在请求的头部（如Authorization头部）或查询参数中携带Token来实现。
服务器验证Token：服务器在接收到带有Token的请求后，使用相应的密钥（对称或非对称）来验证Token的完整性和真实性。它会解析Token的内容，验证签名，并检查Token的有效期、权限等声明。
验证结果返回：服务器根据Token的验证结果，决定是否允许用户访问请求的资源或执行特定操作。如果验证成功，服务器会响应请求并提供所需的数据或操作；如果验证失败，服务器会拒绝访问，并返回相应的错误响应。

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

四、Token 和 Session 的区别

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

存储位置：

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

数据存储方式：

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

存储容量：

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

安全性：

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

跨域支持：

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

扩展性：

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

生命周期和状态管理：

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中提取认证信息，以验证用户的身份和权限。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sC8UKvYA-1688287955903)(E:\Typora\images\typora-user-images\image-20230702162909444.png)]$

JWT具有以下特点：

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

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

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

4、常见的加密方法

对称加密算法：
- AES（Advanced Encryption Standard）：目前最广泛使用的对称加密算法之一，支持128位、192位和256位密钥长度。
- DES（Data Encryption Standard）：早期的对称加密算法，使用56位密钥长度，现已被AES所取代。
- 3DES（Triple Data Encryption Standard）：DES的加强版，通过多次DES算法的迭代来提高安全性。
非对称加密算法：
- RSA（Rivest-Shamir-Adleman）：最常用的非对称加密算法之一，基于数论的复杂性问题，用于数据加密和数字签名。
- ECC（Elliptic Curve Cryptography）：基于椭圆曲线理论的非对称加密算法，提供与RSA相当的安全性，但使用更短的密钥长度，适用于资源受限的环境。
散列函数（哈希函数）：
- 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

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

2、Session

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

3、Token

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

4、JWT

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