May an OAuth 2.0 access token be a 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 (ie, 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 (eg, 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 (eg, 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).
As long as the Authorization Server and the Resource Server agree on what the access token means, it doesn't matter what their content is. So the only reason you could have a problem would be if you were using different libraries or frameworks when implementing those two servers.
链接地址: http://www.djcxy.com/p/8416.html