OAuth 2.0访问令牌可以是JWT吗? [英] May an OAuth 2.0 access token be a JWT?

问题描述

据我所知， OAuth 2.0规范的形式非常模糊access token应该采用:

From what I can tell, the OAuth 2.0 specification is extremely vague in terms of what form an access token should take:

令牌可以表示用于检索授权的标识符 信息或可以以可验证的方式自我包含授权信息(即，由某些数据和签名组成的令牌字符串).为了使客户端使用令牌，可能需要超出本规范范围的其他身份验证凭据.

The token may denote an identifier used to retrieve the authorization information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature). Additional authentication credentials, which are beyond the scope of this specification, may be required in order for the client to use a token.

访问令牌提供了一个抽象层，用资源服务器可以理解的单个令牌替换了不同的授权结构(例如，用户名和密码).这种抽象使发出的访问令牌比获得令牌的授权更严格，并且消除了资源服务器了解各种身份验证方法的需要.

The access token provides an abstraction layer, replacing different authorization constructs (e.g., username and password) with a single token understood by the resource server. This abstraction enables issuing access tokens more restrictive than the authorization grant used to obtain them, as well as removing the resource server's need to understand a wide range of authentication methods.

访问令牌可以具有不同的格式，结构和使用方法(例如，密码属性). 访问令牌属性和用于访问受保护资源的方法超出了本规范的范围，并且由诸如

Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications such as RFC6750.

(添加了重点)

链接的RFC6750没有提供更多的特殊性.有一个示例HTTP响应正文显示:

The linked RFC6750 doesn't offer much further specificity. There is an example HTTP response body that shows:

{
       "access_token":"mF_9.B5f-4.1JqM",
       "token_type":"Bearer",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
     }

这似乎表明access_token可以是不透明的ASCII文本，例如已编码的 JSON Web令牌(JWT)

This seems to indicate that the access_token can be opaque ASCII text such as an encoded JSON Web Token (JWT)

在我看来，JWT-as-access_token似乎具有一些理想的属性:

From my perspective, it seems like JWT-as-access_token has some desirable properties:

• 这是一个已知的规范，具有相当广泛的采用率，并且客户端库支持多种语言.

• It's a known specification, with fairly wide adoption and client libraries available in many languages.

它允许使用经过审查的加密库轻松进行签名和验证.

It allows for easy signing and verification using vetted cryptographic libraries.

由于可以将其解码为JSON，因此我们可以在令牌本身中包含有关令牌的元数据和信息.

Because it can be decoded to JSON, it would allow us to include metadata and information about the token within the token itself.

我的问题是:首先，允许访问令牌成为JWT吗?第二，如果根据规范允许使用JWT作为访问令牌，是否还有其他考虑因素呢?

My questions are: First, is it permissible for the access token to be a JWT? Second, if it is permissible according to the spec, are there any additional considerations that would make using a JWT as an access token a bad idea?

推荐答案

A1:由于规范不限制其格式，因此规范明确允许使用JWT作为访问令牌.

A1: Using a JWT as an access token is certainly permissible by spec exactly because the spec does not restrict its format.

A2:使用JWT作为访问令牌的背后想法是，它可以是独立的，以便目标可以验证访问令牌并使用相关的内容，而不必返回到授权服务器.这是一个很好的特性，但是却使撤销工作更加困难.因此，如果您的系统需要立即撤消访问的功能，那么JWT可能不是访问令牌的正确选择(尽管通过减少JWT的生存期，您可以取得很大的收获).

A2: The idea behind using a JWT as an access token is that it can then be self-contained so that the target can verify the access token and use the associated content without having to go back to the Authorization Server. That is a great property but makes revocation harder. So if your system requires a capability for immediate revocation of access, a JWT is probably not the right choice for an access token (though you can get pretty far by reducing the lifetime of the JWT).

这篇关于OAuth 2.0访问令牌可以是JWT吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！