如何撤销 JWT 令牌? [英] How can I revoke a JWT token?

问题描述

我正在使用 Spring Security OAuth2 和 JWT 令牌.我的问题是:如何撤销 JWT 令牌?

I am using Spring Security OAuth2 and JWT tokens. My question is: How can I revoke a JWT token?

正如这里提到的http://projects.spring.io/spring-security-oauth/docs/oauth2.html，撤销由刷新令牌完成.但它似乎不起作用.

As mentioned here http://projects.spring.io/spring-security-oauth/docs/oauth2.html, revocation is done by refresh token. But it does not seem to work.

推荐答案

通常最简单的答案是说您不能撤销 JWT 令牌，但事实并非如此.诚实的回答是，支持 JWT 撤销的成本足够大，以至于在大多数情况下都不值得，或者直接重新考虑 JWT 的替代方案.

In general the easiest answer would be to say that you cannot revoke a JWT token, but that's simply not true. The honest answer is that the cost of supporting JWT revocation is sufficiently big for not being worth most of the times or plainly reconsider an alternative to JWT.

话虽如此，在某些情况下，您可能同时需要 JWT 和立即撤销令牌，所以让我们来看看需要做什么，但首先我们将介绍一些概念.

Having said that, in some scenarios you might need both JWT and immediate token revocation so lets go through what it would take, but first we'll cover some concepts.

JWT (Learn JSON Web Tokens) 只是指定了一种令牌格式，这个撤销问题也适用于通常称为自包含或按值标记的任何格式.我喜欢后一个术语，因为它与按引用标记形成了很好的对比.

JWT (Learn JSON Web Tokens) just specifies a token format, this revocation problem would also apply to any format used in what's usually known as a self-contained or by-value token. I like the latter terminology, because it makes a good contrast with by-reference tokens.

按值令牌 - 相关信息(包括令牌生命周期)包含在令牌本身中，并且可以验证该信息源自可信来源(用于救援的数字签名)

by-value token - associated information, including token lifetime, is contained in the token itself and the information can be verified as originating from a trusted source (digital signatures to the rescue)

by-reference token - 相关信息保存在服务器端存储中，然后使用令牌值作为键获取；作为服务器端存储，关联信息是隐式可信的

by-reference token - associated information is kept on server-side storage that is then obtained using the token value as the key; being server-side storage the associated information is implicitly trusted

在 JWT Big Bang 之前，我们已经在我们的身份验证系统中处理了令牌；应用程序通常会在用户登录时创建一个会话标识符，然后使用该标识符，这样用户就不必每次都重复登录过程.这些会话标识符被用作服务器端存储的关键索引，如果这听起来与您最近阅读的内容相似，那么您是对的，这确实被归类为按引用标记.

Before the JWT Big Bang we already dealt with tokens in our authentication systems; it was common for an application to create a session identifier upon user login that would then be used so that the user did not had to repeat the login process each time. These session identifiers were used as key indexes for server-side storage and if this sounds similar to something you recently read, you're right, this indeed classifies as a by-reference token.

使用相同的类比，理解按引用令牌的撤销是微不足道的；我们只是删除映射到该密钥的服务器端存储，下次提供该密钥时它将无效.

Using the same analogy, understanding revocation for by-reference tokens is trivial; we just delete the server-side storage mapped to that key and the next time the key is provided it will be invalid.

对于按值令牌，我们只需要实现相反的方法.当您请求撤销令牌时，您会存储一些允许您唯一标识该令牌的内容，以便下次收到它时您可以另外检查它是否已被撤销.如果您已经认为这样的事情不会扩展，请记住您只需要存储数据直到令牌到期，并且在大多数情况下，您可能只存储令牌的哈希值，因此它总是是已知大小的东西.

For by-value tokens we just need to implement the opposite. When you request the revocation of the token you store something that allows you to uniquely identify that token so that next time you receive it you can additionally check if it was revoked. If you're already thinking that something like this will not scale, have in mind that you only need to store the data until the time the token would expire and in most cases you could probably just store an hash of the token so it would always be something of a known size.

作为最后一点，并以 OAuth 2.0 为中心，按值访问令牌的撤销目前尚未标准化.尽管如此，OAuth 2.0 令牌吊销明确指出，只要授权服务器和资源服务器都同意自定义处理方式，它仍然可以实现:

As a last note and to center this on OAuth 2.0, the revocation of by-value access tokens is currently not standardized. Nonetheless, the OAuth 2.0 Token revocation specifically states that it can still be achieved as long as both the authorization server and resource server agree to a custom way of handling this:

在前一种情况下(自包含令牌)，当需要立即撤销访问令牌时，可以使用授权服务器和资源服务器之间的一些(当前非标准化)后端交互.

In the former case (self-contained tokens), some (currently non-standardized) backend interaction between the authorization server and the resource server may be used when immediate access token revocation is desired.

如果你同时控制授权服务器和资源服务器，这很容易实现.另一方面，如果您将授权服务器角色委托给像 Auth0 这样的云提供商或像 Spring OAuth 2.0 这样的第三方组件，您很可能需要以不同的方式处理事情，因为您可能只会获得已经标准化的内容.

If you control both the authorization server and resource server this is very easy to achieve. On the other hand if you delegate the authorization server role to a cloud provider like Auth0 or a third-party component like Spring OAuth 2.0 you most likely need to approach things differently as you'll probably only get what's already standardized.

一个有趣的参考

本文解释了另一种方法:JWT黑名单它包含一些有趣的实践和模式，后跟 RFC7523

This article explain a another way to do that: Blacklist JWT It contains some interesting pratices and pattern followed by RFC7523

这篇关于如何撤销 JWT 令牌?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！