我對JWT的問題是，實際上你很少（在實際經驗中，幾乎從來不？）可以假設JWT中的除了用戶ID之外的任何內容都是長期有效的。對於最簡單的客戶端身份驗證狀態的用例來說，你希望在帳戶被入侵時能夠立即撤銷身份驗證。這意味著你還是必須對每個請求檢查身份驗證資料庫，而你可能可以快速從那裡獲得任何其他聲明。同樣地，對於角色來說；如果你將管理員用戶降級為較低的「類別」用戶，你不會希望這需要幾分鐘才能生效。那麼你最後只剩下一種統一的客戶端ID格式，這在某種程度上是有用的，但並不是JWT的「承諾」（我覺得？）
源讨论JSON Web Token 十週年與未來準備原帖 147 条评论 · 导入时统计把你的经验，加入这段讨论。
> 对于客户端认证状态的最简单使用情况；你希望在账户被入侵时立即撤销认证。这意味着你必须对每个请求都检查认证数据库，而你可能可以快速获取该声明中的其他内容。 顺便说一下，我之前构建了一个系统，成功绕过了“每次访问都要检查数据库以确认撤销”这个问题，效果很好。有两个重要的点需要注意： 1. 撤销（或通常所说的“显式登出”）在很多用户应用模式中其实非常少见。例如，对于许多网页应用，用户很少显式登出。对于移动应用来说，这更少见。 2. 你只需要保留撤销列表直到你的令牌过期时间。例如，如果你的令牌过期时间是30分钟，而你在中午撤销了用户的令牌，到中午12:30你可以删除该记录。…
完整原文活跃用户登出、删除、权限更改的情况很少，因此撤销列表的大小与存在的令牌数量相比非常小。 你可以将撤销信息存储在一个非常快速查找的系统中（例如广播+内存存储），结合合理较短的令牌续订时间，比如5到60分钟。 这大大减少了令牌有效性检查的数量，并使系统在认证系统出现故障时具有容错能力。这对于认证数据与其他数据存储在同一个数据库中的基本应用来说可能不太相关，但在更大的系统中很少是这种情况。
完整原文我认为你的观点比较狭隘。 例如，通过电子邮件发送的魔法链接可以有较长的有效期。
完整原文> 对于客户端认证状态的最简单使用场景；你希望在账户被入侵时能够立即撤销认证。这意味着你必须在每次请求时检查认证数据库，而你可能已经可以快速获取该声明中的其他信息。 我看不到你关于JWT的场景的相关性。我的意思是，我理解你的沮丧。然而，这些与JWT无关。花点时间读读你写的内容：如果你的账户被入侵，攻击者在获得凭证的那一刻就开始滥用这些凭证了。攻击者获得有效凭证的时刻并不是你发现攻击的时刻，更不是你强制被入侵的账户进行全局注销的时刻。这意味着你的场景无法防止滥用。你是在令牌已经被滥用时才进行撤销的。 另外，作为一个实施了基于JWT的系统的人，…
完整原文我有一个关于被入侵令牌的随机想法，可能并不正确。如果在令牌中加入客户端的IP地址呢？那么服务器可以在收到任何来自不同IP地址的请求时拒绝（并标记为被入侵）？我意识到这也会使那些在不同IP地址之间移动的人失效，比如在大型建筑中使用DHCP/无线网络的人。
完整原文如果发生重大泄露，你可以简单地推出新的密钥……使所有当前的JWT失效，强制重新登录……你也可以按用户类型对签名密钥进行分组，以进一步减少刷新次数。
完整原文> 你希望能够在账户被入侵时立即撤销授权 这取决于系统。根据我的经验，有很多应用程序希望能够撤销访问权限，但同时也要考虑透明的重新认证。OIDC 通过以下方式很好地处理了这两方面： * 短暂的访问/身份令牌生命周期（几秒到几分钟） * 定期透明地刷新这些令牌（使用有效期为几天到几个月的刷新令牌） 这种灵活性让开发者可以使用相同的技术来处理银行系统（访问/身份令牌和刷新令牌的生命周期都较短）和消费类应用程序（访问/身份令牌生命周期较短，而刷新令牌生命周期较长）。
完整原文你不需要每次请求都检查数据库。只需将被撤销的令牌列表存储在一个快速缓存中，比如 redis，设置的 ttl 长于最长的令牌生命周期，并拒绝/强制重新认证任何匹配的令牌
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。