May an OAuth 2.0 access token be a JWT?

Question

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?

Solution 1

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).

Solution 2

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.

Solution 3

Currently the OAuth Working Group is working on a JWT profile for OAuth 2.0 access tokens: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Comments

[theblang]

If you needed to revoke access in the event of something catastrophic, you could just change the secrets right?

[user1870400]

changing the secret revokes all the JWT tokens for all the users. I think it gets harder to revoke a JWT token for one user since it is not stored anywhere.

[Hans Z.]

No changing the secret pushes the problem to the timeliness of the key distribution mechanism

[odigity]

There is now an RFC extending OAuth2 with a token revocation endpoint: tools.ietf.org/html/rfc7009 And another, which came out a week ago, for token introspection: tools.ietf.org/html/rfc7662

[Rhubarb]

the trick to revocation is to use a refresh token. The refresh token is supplied by the Authorization Server at the same time as your JWT access token, but has a much longer lifetime and - crucially - can only be used in a request to the Authorization Server to get a new access token (without user interaction). E.g. the AS issues a refresh token that lasts 5 hours and an access JWT that lasts 5 minutes. You get 5 minutes worth of requests with no slow AS calls, and a chance to revoke every 5 minutes (when the Access Token expires and the Refresh token is used to request a new one from the AS)

[Andy]

I don't know if OAuth2 specifies this but access tokens are intended to be verified without hitting the database, so revocation can only happen when the refresh token is verified (which includes a database hit).