讲真，别再使用JWT了！

已于 2023-04-18 14:00:45 修改
阅读量1.1k 收藏 6
点赞数
文章标签： java 开发语言
于 2023-04-18 13:59:27 首次发布
原文链接：https://www.jianshu.com/p/af8360b83a9f
版权

原文链接

https://www.jianshu.com/p/af8360b83a9f

摘要：

  • 在Web应用中，使用JWT替代session并不是个好主意
  • 适合JWT的使用场景

抱歉，当了回标题党。我并不否认JWT的价值，只是它经常被误用。

什么是JWT

根据维基百科的定义，JSON WEB Token（JWT，读作 [/dʒɒt/]），是一种基于JSON的、用于在网络上声明某种主张的令牌（token）。JWT通常由三部分组成: 头信息（header）, 消息体（payload）和签名（signature）。

头信息指定了该JWT使用的签名算法:

header = '{"alg":"HS256","typ":"JWT"}'

HS256 表示使用了 HMAC-SHA256 来生成签名。

消息体包含了JWT的意图：

payload = '{"loggedInAs":"admin","iat":1422779638}'//iat表示令牌生成的时间

未签名的令牌由base64url编码的头信息和消息体拼接而成（使用"."分隔），签名则通过私有的key计算而成：

key = 'secretkey'  
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)  
signature = HMAC-SHA256(key, unsignedToken)

最后在未签名的令牌尾部拼接上base64url编码的签名（同样使用"."分隔）就是JWT了：

token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature) 

# token看起来像这样: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

JWT常常被用作保护服务端的资源（resource），客户端通常将JWT通过HTTP的Authorization header发送给服务端，服务端使用自己保存的key计算、验证签名以判断该JWT是否可信：

Authorization: Bearer eyJhbGci*...<snip>...*yu5CSpyHI

那怎么就误用了呢

近年来RESTful API开始风靡，使用HTTP header来传递认证令牌似乎变得理所应当，而单页应用（SPA）、前后端分离架构似乎正在促成越来越多的WEB应用放弃历史悠久的cookie-session认证机制，转而使用JWT来管理用户session。支持该方案的人认为：

1.该方案更易于水平扩展

在cookie-session方案中，cookie内仅包含一个session标识符，而诸如用户信息、授权列表等都保存在服务端的session中。如果把session中的认证信息都保存在JWT中，在服务端就没有session存在的必要了。当服务端水平扩展的时候，就不用处理session复制（session replication）/ session黏连（sticky session）或是引入外部session存储了。

img

从这个角度来说，这个优点确实存在，但实际上外部session存储方案已经非常成熟了（比如Redis），在一些Framework的帮助下（比如spring-session和hazelcast），session复制也并没有想象中的麻烦。所以除非你的应用访问量非常非常非常（此处省略N个非常）大，使用cookie-session配合外部session存储完全够用了。

2.该方案可防护CSRF攻击

跨站请求伪造Cross-site request forgery（简称CSRF, 读作 [sea-surf]）是一种典型的利用cookie-session漏洞的攻击，这里借用spring-security的一个例子来解释CSRF：

假设你经常使用bank.example.com进行网上转账，在你提交转账请求时bank.example.com的前端代码会提交一个HTTP请求:

POST /transfer HTTP/1.1
Host: bank.example.com
cookie: JsessionID=randomid; Domain=bank.example.com; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded

amount=100.00&routingNumber=1234&account=9876

你图方便没有登出bank.example.com，随后又访问了一个恶意网站，该网站的HTML页面包含了这样一个表单：

<form action="https://bank.example.com/transfer" method="post">
    <input type="hidden" name="amount" value="100.00"/>
    <input type="hidden" name="routingNumber" value="evilsRoutingNumber"/>
    <input type="hidden" name="account" value="evilsAccountNumber"/>
    <input type="submit" value="点击就送!"/>
</form>

你被“点击就送”吸引了，当你点了提交按钮时你已经向攻击者的账号转了100元。现实中的攻击可能更隐蔽，恶意网站的页面可能使用Javascript自动完成提交。尽管恶意网站没有办法盗取你的session cookie（从而假冒你的身份），但恶意网站向bank.example.com发起请求时，你的cookie会被自动发送过去。

因此，有些人认为前端代码将JWT通过HTTP header发送给服务端（而不是通过cookie自动发送）可以有效防护CSRF。在这种方案中，服务端代码在完成认证后，会在HTTP response的header中返回JWT，前端代码将该JWT存放到Local Storage里待用，或是服务端直接在cookie中保存HttpOnly=false的JWT。

img

在向服务端发起请求时，用Javascript取出JWT（否则前端Javascript代码无权从cookie中获取数据），再通过header发送回服务端通过认证。由于恶意网站的代码无法获取bank.example.com的cookie/Local Storage中的JWT，这种方式确实能防护CSRF，但将JWT保存在cookie/Local Storage中可能会给另一种攻击可乘之机，我们一会详细讨论它：跨站脚本攻击——XSS。

3.该方案更安全

由于JWT要求有一个秘钥，还有一个算法，生成的令牌看上去不可读，不少人误认为该令牌是被加密的。但实际上秘钥和算法是用来生成签名的，令牌本身不可读仅是因为base64url编码，可以直接解码，所以如果JWT中如果保存了敏感的信息，相对cookie-session将数据放在服务端来说，更不安全。

除了以上这些误解外，使用JWT管理session还有如下缺点：

  1. **更多的空间占用。**如果将原存在服务端session中的各类信息都放在JWT中保存在客户端，可能造成JWT占用的空间变大，需要考虑cookie的空间限制等因素，如果放在Local Storage，则可能受到XSS攻击。
  2. **更不安全。**这里是特指将JWT保存在Local Storage中，然后使用Javascript取出后作为HTTP header发送给服务端的方案。在Local Storage中保存敏感信息并不安全，容易受到跨站脚本攻击，跨站脚本（Cross site script，简称xss）是一种“HTML注入”，由于攻击的脚本多数时候是跨域的，所以称之为“跨域脚本”，这些脚本代码可以盗取cookie或是Local Storage中的数据。可以从这篇文章查看XSS攻击的原理解释。
  3. **无法作废已颁布的令牌。**所有的认证信息都在JWT中，由于在服务端没有状态，即使你知道了某个JWT被盗取了，你也没有办法将其作废。在JWT过期之前（你绝对应该设置过期时间），你无能为力。
  4. **不易应对数据过期。**与上一条类似，JWT有点类似缓存，由于无法作废已颁布的令牌，在其过期前，你只能忍受“过期”的数据。

看到这里后，你可能发现，将JWT保存在Local Storage中，并使用JWT来管理session并不是一个好主意，那有没有可能“正确”地使用JWT来管理session呢？比如：

  • 不再使用Local Storage存储JWT，使用cookie，并且设置HttpOnly=true，这意味着只能由服务端保存以及通过自动回传的cookie取得JWT，以便防御XSS攻击
  • 在JWT的内容中加入一个随机值作为CSRF令牌，由服务端将该CSRF令牌也保存在cookie中，但设置HttpOnly=false，这样前端Javascript代码就可以取得该CSRF令牌，并在请求API时作为HTTP header传回。服务端在认证时，从JWT中取出CSRF令牌与header中获得CSRF令牌比较，从而实现对CSRF攻击的防护
  • 考虑到cookie的空间限制（大约4k左右），在JWT中尽可能只放“够用”的认证信息，其他信息放在数据库，需要时再获取，同时也解决之前提到的数据过期问题

这个方案看上去是挺不错的，恭喜你，你重新发明了cookie-session，可能实现还不一定有现有的好。

那究竟JWT可以用来做什么

我的同事做过一个形象的解释：

JWT（其实还有SAML）最适合的应用场景就是“开票”，或者“签字”。

在有纸化办公时代，多部门、多组织之间的协同工作往往会需要拿着A部门领导的“签字”或者“盖章”去B部门“使用”或者“访问”对应的资源，其实这种“领导签字／盖章”就是JWT，都是一种由具有一定权力的实体“签发”并“授权”的“票据”。一般的，这种票据具有可验证性（领导签名／盖章可以被验证，且难于模仿），不可篡改性（涂改过的文件不被接受，除非在涂改处再次签字确认）；并且这种票据一般都是“一次性”使用的，在访问到对应的资源后，该票据一般会被资源持有方收回留底，用于后续的审计、追溯等用途。

举两个例子：

  1. 员工李雷需要请假一天，于是填写请假申请单，李雷在获得其主管部门领导签字后，将请假单交给HR部门韩梅梅，韩梅梅确认领导签字无误后，将请假单收回，并在公司考勤表中做相应记录。
  2. 员工李雷和韩梅梅因工外出需要使用公司汽车一天，于是填写用车申请单，签字后李雷将申请单交给车队司机老王，乘坐老王驾驶的车辆外出办事，同时老王将用车申请单收回并存档。

在以上的两个例子中，“请假申请单”和“用车申请单”就是JWT中的payload，领导签字就是base64后的数字签名，领导是issuer，“HR部门的韩梅梅”和“司机老王”即为JWT的audience，audience需要验证领导签名是否合法，验证合法后根据payload中请求的资源给予相应的权限，同时将JWT收回。

放到系统集成的场景中，JWT更适合一次性操作的认证:

服务B你好, 服务A告诉我，我可以操作<JWT内容>, 这是我的凭证（即JWT）

在这里，服务A负责认证用户身份（相当于上例中领导批准请假），并颁布一个很短过期时间的JWT给浏览器（相当于上例中的请假单），浏览器（相当于上例中的请假员工）在向服务B的请求中带上该JWT，则服务B（相当于上例中的HR员工）可以通过验证该JWT来判断用户是否有权执行该操作。这样，服务B就成为一个安全的无状态的服务了。

总结

  1. 在Web应用中，别再把JWT当做session使用，绝大多数情况下，传统的cookie-session机制工作得更好
  2. JWT适合一次性的命令认证，颁发一个有效期极短的JWT，即使暴露了危险也很小，由于每次操作都会生成新的JWT，因此也没必要保存JWT，真正实现无状态。

文／ThoughtWorks 周宇刚

万垄丘
关注
laravel-JWT 完整使用详解
wgchen
01-18 1312
简介 JWT 全称 JSON Web Tokens ，是一个非常轻巧的规范。这个规范允许我们使用 JWT 在用户和服务器之间传递安全可靠的信息。它的两大使用场景是：认证和数据交换。 JWT 超详细分析 参考文献：https://learnku.com/articles/17883 Laravel 使用 JWT 完整使用详解 1. 使用 composer 安装 # 建议使用1.0以上版本 composer require tymon/jwt-auth 1.*@rc 2. 进行一些配置 这里值得注意的是，有些
jwt oauth2 对接_使用JWT的OAuth2的SSO分析
weixin_39617006的博客
12-20 619
参考:https://github.com/spring-guides/tut-spring-security-and-angular-js/blob/master/oauth2/README.adochttp://jwt.io/introduction/本文在文章的基础上扩展,使用jwt可减少了向认证服务器的请求,但jwt比swt(Simple Web Tokens)要长不少,还要依赖公钥解密....
公司新来一个 CTO：禁止使用 JWT 存储 Session，发现请立即走人！
2401_83384536的博客
11-28 856
原文作者：Wi1dcard转自链接：https://learnku.com/articles/22616原文地址：http://cryto.net/~joepie91/blog/JSON Web Tokens，又称JWT。本文将详解：为何 JWT 不适合存储 Session，以及 JWT 引发的安全隐患。望各位对JWT有更深的理解！十分不幸，我发现越来越多的人开始推荐使用 JWT 管理网站的用户会话（Session在本文中，我将说明为何这是个非常非常不成熟的想法。
branca：安全替代JWT。 经过验证的Go加密API令牌
01-30
布兰卡 branca是JWT的安全替代方案，此实现是用纯Go语言编写的（无cgo依赖项），并且实现了。 要求 转到1.13+ 安装 go get -u github.com/hako/branca 例 package main import ( "fmt" "github.com/hako/branca" ) func main () { b := branca . NewBranca ( "supersecretkeyyoushouldnotcommit" ) // This key must be exactly 32 bytes long. // Encode String to Branca Token. token , err := b . EncodeToString ( "Hello world!" ) if err != nil { fmt . Println ( err ) } //b.SetTTL(3600) // Uncomment this to set an expiration (or ttl) of the tok
为什么很多人不推荐使用JWT？
最新发布
dotNET跨平台
05-06 77
JWT并非适用于所有场景，尤其在需要动态会话管理、高安全性或高性能的Web应用中，传统基于Cookie和服务器端会话的机制更具优势。若用户注销或密码被修改，旧令牌仍可在有效期内使用，除非引入黑名单机制（需额外存储，违背无状态初衷）：相比传统会话ID（仅几字节），JWT包含头部、载荷和签名，体积可能显著增加（尤其载荷包含大量数据时），导致带宽消耗和传输延迟。：JWT的无状态特性虽适合分布式系统，但大多数应用通过Redis等集中存储即可实现会话扩展，无需引入JWT的复杂性。
别再使用 JWT 作为 Session 系统！问题重重且很危险。
方志朋的博客
11-24 331
点击关注公众号，Java干货及时送达????来源：learnku.com/articles/22616首先需要说明JWT 坊间流传的优势易于水平扩展？易于使用？更加灵活？更加安全？内置过期时间功能？无需询问用户「本网站使用 Cookies」？防止 CSRF 攻击？更适用于移动端？适用于阻止 Cookies 的用户？JWT 的劣势更费空间更不安全无法单独销毁数据延迟实现库缺乏生产环境验证或压根不存在结论所...
推荐：branca - 安全的JWT替代方案
gitblog_00024的博客
06-04 790
推荐：branca - 安全的JWT替代方案 branca:key: Secure alternative to JWT. Authenticated Encrypted API Tokens for Go.项目地址:https://gitcode.com/gh_mirrors/br/branca 项目介绍 在寻找一种安全且高效的身份验证机制吗？branca 是一个值得您关注的项目。它是基于纯 ...
取代JWT，使用Redis来管理Token
weixin_41070914的博客
04-13 1686
模仿JWT，写基于Redis的鉴权Token管理，解决JWT是无状态的问题，JWT续期流程略麻烦，得前端配合更换TOKEN 示例代码使用Spring Boot编写 代码已经上传码云 Redis_Token示例 示例代码已经集成全局异常拦截，拦截器配置等等，下载了可以根据自己业务需求去更改。 ...
web 开发中jwt的使用
一路奔跑94的博客
04-28 2948
摘要： 在Web应用中，使用JWT替代session并不是个好主意 适合JWT的使用场景 抱歉，当了回标题党。我并不否认JWT的价值，只是它经常被误用。 网友看法： jwt最致命的问题，就是将用户标识明文（base64等同明文）的放在客户端，而且单一依赖同一个secret。一旦secret被泄露，那攻击者就可以毫不费力的冒充所有用户。而不幸的是，secret的保护并不足够：1. 一般作为配...
如何使用 JWT 身份验证保护 REST API
分享身边生活经验blog
10-15 1459
JSON Web 令牌是一种开放的标准方式，您可以在两方交互期间安全地表示用户的身份。当两个系统交换数据时，您可以使用 JSON Web 令牌来识别您的用户，而无需在每个请求上发送私有凭据。如果将其应用于 REST API，您将看到我们的客户端-服务器交互如何从这些机制中受益：首先，用户或客户端应用程序发送登录请求。在此步骤中，用户提供的用户名、密码或任何其他类型的登录凭据本质上都会传送到 API。验证后，API 将创建一个 JSON Web 令牌并使用密钥对其进行签名。
jwt 例子 java_利用Springboot实现Jwt认证的示例代码
weixin_34452012的博客
02-13 384
JSON Web Token是目前最流行的跨域认证解决方案,，适合前后端分离项目通过Restful API进行数据交互时进行身份认证概述由于概念性内容网上多的是，所以就不详细介绍了具体可以看这里：阮一峰大佬的博客我总结几个重点：JWT，全称Json Web Token，是一种令牌认证的方式长相：头部：放有签名算法和令牌类型(这个就是JWT)载荷：你在令牌上附带的信息：比如用户的id，用户的电话号码...
RuoYi-Vue（RuoYi）：基于SpringBoot的官方仓库，Spring Security，JWT，Vue＆Element的前替代分离权限管理系统
02-06
平台简介 若依是一套全部开源的快速开发平台，毫无保留给个人及企业免费使用。 前端采用Vue，Element UI。 初步采用Spring Boot，Spring Security，Redis＆Jwt。 权限认证使用Jwt，支持多终端认证系统。 支持加载动态权限菜单，多方式轻松权限控制。 高效率开发，使用代码生成器可以一键生成前的代码。 提供了单应用版本 ，Oracle版本 ，保持同步更新。 不分离版本，请移步 ，微服务版本，请移步 特别鸣谢： ， ， 。 阿里云折扣场：，腾讯云秒杀场： 阿里云优惠券： ，腾讯云优惠券： 内置功能 用户管理：用户是系统操作者，该功能主要完成系统用户配置。
基于jwt的token验证、原理及流程
2401_85239883的博客
07-23 1962
就写到这了，也算是给这段时间的面试做一个总结，查漏补缺，祝自己好运吧，也希望正在求职或者打算跳槽的 程序员看到这个文章能有一点点帮助或收获，我就心满意足了。多思考，多问为什么。希望小伙伴们早点收到满意的offer!越努力越幸运！金九银十已经过了，就目前国内的面试模式来讲，在面试前积极的准备面试，复习整个 Java 知识体系将变得非常重要，可以很负责任的说一句，复习准备的是否充分，将直接影响你入职的成功率。
探索安全认证新境界：Branca，JWT的优质替代方案
gitblog_00634的博客
08-25 521
探索安全认证新境界：Branca，JWT的优质替代方案 项目地址:https://gitcode.com/gh_mirrors/br/branca 在当今这个高度数字化的时代，数据的安全传输与验证显得至关重要。JWT（JSON Web Tokens）作为广泛使用的身份验证和授权机制，虽然便捷，但随着安全性需求的提升，开发者们不断寻求更强大、更安全的解决方案。今天，我们来探索一个新兴的明星——Bra...
我不应该用JWT的！
2301_78976656的博客
07-16 924
JWT: 生成并发给客户端之后，后台是不用存储，客户端访问时会验证其签名、过期时间等再取出里面的信息（如username），再使用该信息直接查询用户信息完成登录验证。jwt自带签名、过期等校验，后台不用存储，缺陷是一旦下发，服务后台无法拒绝携带该jwt的请求（如踢除用户）；Token+Redis： 是自己生成个32位的key，value为用户信息，访问时判断redis里是否有该token，如果有，则加载该用户信息完成登录。
不要使用 JWT 进行会话管理
weixin_30834783的博客
10-12 342
英文原文地址：Stop using JWT for sessions 最近我发现越来越多的人推荐使用 JWT 来在 Web 应用中管理会话（Session），这是一个非常非常糟糕的主意，在这篇文章中我会详细地解释为什么“不要使用 JWT 进行会话管理”。 为了方便叙述的同时避免混淆，我需要先定义一些概念： 无状态 JWT（Stateless JWT）：一个包含了所有会话相关数据的 JW...
Branca：Go语言下的安全替代JWT方案
gitblog_00212的博客
12-26 393
Branca：Go语言下的安全替代JWT方案 branca :key: Secure alternative to JWT. Authenticated Encrypted API Tokens for Go. 项目地址: htt...
gtoken替换jwt实现sso登录
Maisucsdn的博客
05-20 1142
今天和大家分享一下使用gtoken替换jwt实现sso登录的经验，为了让大家更好的理解会带大家读一下重点的源码。 jwt的问题 首先说明一个jwt存在的问题，也就是要替换jwt的原因： jwt无法在服务端主动退出的问题 jwt无法作废已颁布的令牌，只能等到令牌过期问题 jwt携带大量用户扩展信息导致降低传输效率问题 jwt的请求流程图 gtoken的优势 gtoken的请求流程和jwt的基本一致。 gtoken的优势就是能帮助我们解决jwt的问题，另外还提供好用的特性，比如： gtok
jwt自动续期方案设计
04-02
<think>好的，我现在需要处理用户关于JWT自动续期设计方案的问题。首先，我需要回顾一下JWT的基本概念和自动续期的常见方法。用户提到他们想了解实现方案、设计以及最佳实践，所以我需要涵盖这些方面。 首先，JWT通常由三部分组成：头部、载荷和签名。自动续期一般是为了让用户无感延长会话，而不需要频繁重新登录。常见的方案包括双Token机制，也就是Access Token和Refresh Token的组合。Access Token有效期较短，比如30分钟，而Refresh Token较长，比如7天。当Access Token过期后，用Refresh Token去获取新的Access Token。这样即使Access Token被盗，攻击者的使用时间也有限。 接下来需要考虑如何实现这个机制。用户可能想知道具体的步骤，比如客户端存储的方式，服务端如何验证和签发新的Token。同时安全性也是一个重点，比如Refresh Token需要安全存储，防止泄露。另外，是否需要每次请求都检查Token的有效期，或者在中间件中处理续期逻辑。 然后是最佳实践，比如如何设置合理的过期时间，使用HTTPS来传输Token，以及监控和日志记录。可能还需要提到单点登录（SSO）和分布式系统中的一致性处理，比如将Refresh Token存入Redis集群，并设置自动过期。 用户提供的引用中有提到双Token机制和Token自动续期的核心原理，需要结合这些信息。引用[2]特别提到双Token机制，所以应该详细说明这一点。同时，引用[1]虽然主要讲Spring Cloud，但可能涉及到安全与认证的部分，可以联系起来。 还需要考虑可能的攻击方式，比如如何防止Refresh Token被窃取，是否需要绑定用户设备或IP，或者加入二次验证。此外，前端如何无感地处理Token续期，比如在拦截器中捕获401错误后自动调用刷新接口。 最后，生成相关问题，帮助用户进一步探索。比如如何防止Token被盗用，如何在高并发下处理续期，或者与OAuth2的集成等。 总结一下，回答的结构应该是先介绍核心原理（双Token机制），然后分步骤说明实现方案，接着讨论安全措施，最后列出最佳实践。确保每个部分都清晰，并且引用提供的参考文献中的内容。</think># JWT自动续期设计方案与最佳实践 ## 一、核心设计原理：双Token机制[^2] 采用Access Token + Refresh Token的双令牌体系实现无感续期： $$AccessToken_{exp}=30min,\quad RefreshToken_{exp}=7d$$ 前端通过响应拦截器自动处理401状态码，使用Refresh Token请求新令牌。当Refresh Token剩余有效期小于阈值时触发强制重新认证。 ## 二、具体实现方案 ### 1. 令牌签发阶段 ```python # 生成带刷新标识的令牌对 def generate_tokens(user): access_payload = {"uid":user.id, "exp":datetime.utcnow()+timedelta(minutes=30)} refresh_payload = {"uid":user.id, "rt":True, "exp":datetime.utcnow()+timedelta(days=7)} access_token = jwt.encode(access_payload, SECRET_KEY, algorithm='HS256') refresh_token = jwt.encode(refresh_payload, SECRET_KEY, algorithm='HS256') # 将refresh_token存储到Redis并设置自动过期 redis.setex(f"refresh:{user.id}", 604800, refresh_token) # 7天=604800秒 return {"access_token": access_token, "refresh_token": refresh_token} ``` ### 2. 令牌刷新接口设计 ```python @app.route('/refresh', methods=['POST']) def refresh_tokens(): refresh_token = request.headers.get('Authorization') try: payload = jwt.decode(refresh_token, SECRET_KEY, algorithms=['HS256']) if not payload.get('rt'): raise InvalidTokenError("非刷新令牌") # 验证Redis存储的令牌一致性 stored_token = redis.get(f"refresh:{payload['uid']}") if stored_token != refresh_token: raise TokenMismatchError("令牌已失效") return generate_tokens(payload['uid']) except jwt.ExpiredSignatureError: return {"error": "需要重新登录"}, 401 ``` ## 三、安全增强措施 1. **传输安全**：所有Token传输必须通过HTTPS 2. **存储防护**： - 前端使用`httpOnly` + `Secure`的Cookie存储Refresh Token - Access Token存储在内存或Session Storage 3. **绑定校验**： - 在Token payload中记录签发IP/设备指纹 - 刷新时校验User-Agent等客户端特征 4. **监控预警**： - 记录异常刷新请求 - 设置单位时间刷新频率阈值 ## 四、最佳实践建议 1. **时间设置优化**： - Access Token有效期建议$15\text{min} \leq T_{access} \leq 2\text{h}$ - Refresh Token有效期建议$7\text{d} \leq T_{refresh} \leq 30\text{d}$ 2. **吊销机制**： ```mermaid graph LR A[用户登出] --> B[删除Redis中的refresh_token] C[修改密码] --> B D[检测异常] --> B ``` 3. **分布式系统处理**： - 使用Redis Cluster存储Refresh Token - 采用JWT黑名单机制处理即时吊销
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值