JWT Access Tokens Profile for OAuth 2.0
Fleeting- External reference: https://datatracker.ietf.org/doc/html/rfc9068
- External reference: https://oauth.net/2/jwt-access-tokens/
JWT Access Tokens for OAuth 2.0
the claims not established herein but used in examples and descriptions, such as iss, sub, exp, etc., are defined by [JWT].
[…]
- “act” (Actor) Claim
- “scope” (Scopes) Claim
- “client_id” (Client Identifier) Claim
- “may_act” (Authorized Actor) Claim
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
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
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.
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.
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.
link with audience claim
If the request includes a “resource” parameter (as defined in [RFC8707]), the resulting JWT access token “aud” claim SHOULD have the same value as the “resource” parameter in the request.
[…]
If the request does not include a “resource” parameter, the authorization server MUST use a default resource indicator in the “aud” claim.
link with well-known/oauth-authorization-server and well-known/openid-configuration
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. Alternatively, authorization servers implementing OpenID Connect MAY use the OpenID Connect discovery [OpenID.Discovery] document for the same purpose
If an authorization server supports both OAuth 2.0 Authorization Server Metadata and OpenID Connect discovery, the values provided MUST be consistent across the two publication
Notes linking here
- is the bearer token opaque?
- JWT Access Tokens profile for OAuth 2.0 may be different from implementations
- keycloak provide many user related information in the access token by default.
- making sense of github OIDC flow
- oauth - what’s the meaning of the “gty” claim in a jwt token?
- OAuth 2.0
- oauth 2.0 client