Konubinix' opinionated web of thoughts

JWT Access Tokens Profile for OAuth 2.0

fleeting

JWT Access Tokens for OAuth 2.0

The JWT Access Token profile describes a way to encode access tokens as a JSON Web Token, including a set of standard claims that are useful in an access token

https://oauth.net/2/jwt-access-tokens/

often include resource owner attributes directly in access tokens so that resource servers can consume them directly for authorization or other purposes without any further round trips to introspection

https://datatracker.ietf.org/doc/html/rfc9068

JWTs can be used as OAuth 2.0 Bearer Tokens to encode all relevant parts of an access token into the access token itself instead of having to store them in a database

https://oauth.net/2/jwt-access-tokens/

This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format.

https://datatracker.ietf.org/doc/html/rfc9068

Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner

https://datatracker.ietf.org/doc/html/rfc9068

original OAuth 2.0 Authorization Framework specification does not mandate any specific format for access tokens

https://datatracker.ietf.org/doc/html/rfc9068

in-market use has shown that many commercial OAuth 2.0 implementations elected to issue access tokens using a format that can be parsed and validated by resource servers directly, without further authorization server involvement

https://datatracker.ietf.org/doc/html/rfc9068

At the time of writing, many commercial implementations leverage the JSON Web Token (JWT)

https://datatracker.ietf.org/doc/html/rfc9068

authorization servers will often include resource owner attributes directly in access tokens so that resource servers can consume them directly for authorization or other purposes without any further round trips to introspection or UserInfo endpoints

https://datatracker.ietf.org/doc/html/rfc9068

This profile does not introduce any mechanism for a client to directly request the presence of specific claims in JWT access tokens, as the authorization server can determine what additional claims are required by a particular resource server by taking the client_id of the client and the “scope” and the “resource” parameters included in the request into consideration.

https://datatracker.ietf.org/doc/html/rfc9068

Many authorization servers embed authorization attributes that go beyond the delegated scenarios described by [RFC7519] in the access tokens they issue.

Typical examples include resource owner memberships in roles and groups that are relevant to the resource being accessed, entitlements assigned to the resource owner for the targeted resource that the authorization server knows about, and so on.

An authorization server wanting to include such attributes in a JWT access token SHOULD use the “groups”, “roles”, and “entitlements” attributes of the “User” resource schema defined by Section 4.1.2 of [RFC7643]) as claim types.

https://datatracker.ietf.org/doc/html/rfc9068

Authorization servers SHOULD use OAuth 2.0 Authorization Server Metadata [RFC8414] to advertise to resource servers their signing keys via “jwks_uri” and what “iss” claim value to expect via the “issuer” metadata value.

https://datatracker.ietf.org/doc/html/rfc9068

Notes linking here