Is the Bearer Token Opaque?
FleetingAs per the spec:
Bearer Token
A security token with the property that any party in possession of the token (a “bearer”) can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).
It says that it is named bearer because it is meant to be transported as-is by the client. But it does not indicate that by nature, the client must not open it.
When referring to the access token the spec says:
access token is a string representing an authorization issued to the client. The string is usually opaque to the client
It takes a side, but still remains vague enough, it is usually opaque.
I understand that the intention is to make it opaque, while accepting exceptions.
But, the oauth website (supposedly the guys behind the spec) is more opinionated:
Bearer Token is an opaque string, not intended to have any meaning to clients using it. Some servers will issue tokens that are a short string of hexadecimal characters, while others may use structured tokens such as JSON Web Tokens.
Here, the nuance is gone: the bearer token is opaque.
Finally, in the same site, one can read
- ID tokens are meant to be read by the OAuth client. Access tokens are meant to be read by the resource server.
- ID tokens are JWTs. Access tokens can be JWTs but may also be a random string.
- ID tokens should never be sent to an API. Access tokens should never be read by the client
Here as well, access tokens should never be read by the client clearly states their opinion.
I like the idea of an supposedly opaque token, but with still a way for the client to read it (it helps debugging difficult situations after all).
It appears to be a consensus to assume that the client won’t look at the token.
Per the OAuth specification, access tokens are opaque strings without a set format - some identity providers (IDPs) use GUIDs, others use encrypted blobs
— https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens#claims-in-access-token
Clients must treat access tokens as opaque strings because the contents of the token are intended for the resource (the API) only
— https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens#claims-in-access-token
The client MUST NOT inspect the content of the access token: the authorization server and the resource server might decide to change the token format at any time (for example, by switching from this profile to opaque tokens); hence, any logic in the client relying on the ability to read the access token content would break without recourse. The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.
Notes linking here
- how do I create an OAuth 2.0/OIDC resource server? (blog)
- metaphor of the hotel
- reference token vs self-encoded access token