OAuth 2.0 访问令牌可以是 JWT 吗? [英] May an OAuth 2.0 access token be a JWT?
问题描述
据我所知，OAuth 2.0 规范是在访问令牌应该采用什么形式方面非常模糊:
令牌可能表示用于检索授权的标识符信息或可以以可验证的方式自包含授权信息(即，由一些数据和签名组成的令牌字符串).为了让客户端使用令牌，可能需要额外的身份验证凭据，这超出了本规范的范围.
<块引用>
访问令牌提供了一个抽象层，用资源服务器理解的单个令牌替换了不同的授权结构(例如，用户名和密码).这种抽象使得颁发访问令牌比用于获取它们的授权更严格，并且消除了资源服务器了解各种身份验证方法的需要.
<块引用>
访问令牌可以具有不同的格式、结构和基于资源服务器安全要求的使用方法(例如，加密属性).访问令牌属性和用于访问受保护资源的方法超出了本规范的范围，并由诸如 RFC6750.
(强调)
链接的 RFC6750 没有提供更多的特殊性.有一个示例 HTTP 响应正文显示:
<代码>{access_token":mF_9.B5f-4.1JqM"，token_type":承载"，expires_in":3600，refresh_token":tGzv3JOkF0XG5Qx2TlKWIA"}这似乎表明 access_token 可以是不透明的 ASCII 文本，例如编码的 JSON 网络令牌 (JWT)
从我的角度来看，JWT-as-access_token 似乎有一些理想的属性:
这是一个众所周知的规范，具有相当广泛的采用和多种语言的客户端库.
它允许使用经过审查的加密库轻松签名和验证.
因为它可以被解码为 JSON，所以它允许我们在令牌本身中包含有关令牌的元数据和信息.
我的问题是:首先，访问令牌可以是 JWT 吗?其次，如果根据规范是允许的，是否还有其他考虑因素会使使用 JWT 作为访问令牌成为一个坏主意?
A1:规范当然允许使用 JWT 作为访问令牌，因为规范没有限制其格式.
A2:使用 JWT 作为访问令牌背后的想法是它可以是自包含的，以便目标可以验证访问令牌并使用关联的内容，而无需返回授权服务器.这是一个很好的属性，但会使撤销变得更加困难.因此，如果您的系统需要立即撤销访问权限的功能，那么 JWT 可能不是访问令牌的正确选择(尽管您可以通过缩短 JWT 的生命周期来获得更多收益).
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.
(emphasis added)
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"
}
This seems to indicate that the access_token can be opaque ASCII text such as an encoded JSON Web Token (JWT)
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.
Because it can be decoded to JSON, it would allow us to include metadata and information about the token within the token itself.
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: Using a JWT as an access token is certainly permissible by spec exactly because the spec does not restrict its format.
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屋！
