JWT Access Tokens Profile for OAuth 2.0fleeting
- External reference: https://oauth.net/2/jwt-access-tokens/
- External reference: https://datatracker.ietf.org/doc/html/rfc9068
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
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
This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format.
Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner
original OAuth 2.0 Authorization Framework specification does not mandate any specific format for access tokens
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
At the time of writing, many commercial implementations leverage the JSON Web Token (JWT)
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
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.
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.
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.
Notes linking here
- is the bearer token opaque?
- keycloak provide many user related information in the access token by default.
- OAuth 2.0
- oauth 2.0 client