RFC 9068

JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

📅 published October 2021, from ietf

Title Block Tea, Bestie 🎀

Okay so this is RFC 9068, and the title is JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens 💖. It's a Standards Track document from the IETF, published October 2021 (ISSN 2070-1721), written by V. Bertocci from Auth0. It doesn't obsolete or update any other RFC, so it's a fresh start, no drama 🌸.

The whole point is a profile for issuing OAuth 2.0 access tokens in JWT format ✨. Authorization servers and resource servers from different vendors can use it to issue and consume access tokens in an interoperable way, which is literally the dream 🫶.

Status of This Memo ✨

This is an Internet Standards Track document 🎀.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 💅. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 🦋.

Info about the current status, errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9068 💌.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the publication date 📜. Read them carefully, because they spell out your rights and restrictions. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license 🫶.

Table of Contents 🧚

1.  Introduction
  1.1.  Requirements Notation and Conventions
  1.2.  Terminology
2.  JWT Access Token Header and Data Structure
  2.1.  Header
  2.2.  Data Structure
    2.2.1.  Authentication Information Claims
    2.2.2.  Identity Claims
    2.2.3.  Authorization Claims
      2.2.3.1.  Claims for Authorization Outside of Delegation
                Scenarios
3.  Requesting a JWT Access Token
4.  Validating JWT Access Tokens
5.  Security Considerations
6.  Privacy Considerations
7.  IANA Considerations
  7.1.  Media Type Registration
    7.1.1.  Registry Content
  7.2.  Claims Registration
    7.2.1.  Registry Content
      7.2.1.1.  Roles
      7.2.1.2.  Groups
      7.2.1.3.  Entitlements
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Author's Address

1. Introduction 💖

Okay so the original OAuth 2.0 Authorization Framework [RFC6749] doesn't force any specific format for access tokens 🦋. That's totally fine for lots of situations, but in the real world, lots of commercial OAuth 2.0 setups just issued access tokens that resource servers could parse and validate directly, without asking the authorization server again 🔥. This is especially popular when the authorization server and resource server aren't hosted together, aren't run by the same entity, or are split by some boundary. Right now, a lot of commercial setups use the JSON Web Token (JWT) [RFC7519] format 💅.

Lowkey, a lot of these vendor-specific JWT access tokens look pretty similar 🌸. They use JWT claims to carry what's needed for common stuff like token validation, passing along scopes and entitlements, carrying identity info about the subject, and so on ✨. The differences are mostly the claim names and syntax used for the same things, so interop could be pretty easy if everyone agreed on a shared set of claims and validation rules 🎀.

It's not just commercial stuff, either 🌈. Various OAuth 2.0 family specs, like resource indicators [RFC8707], OAuth 2.0 bearer token usage [RFC6750], and others, assume access tokens have scoping mechanisms, such as an audience 👑. The introspection family of specs also hints at a basic set of info that access tokens are expected to carry, or at least be associated with 🧚.

This spec is here to give us a standardized, interoperable profile as the alternative to the proprietary JWT access token layouts going forward 🦋. Besides a shared set of mandatory and optional claims, it explains how authorization request parameters shape the content of the issued JWT access token, how an authorization server can publish metadata about the JWT access tokens it issues, and how a resource server should validate incoming JWT access tokens 💜.

It also includes security and privacy considerations to help avoid common mistakes and anti-patterns that pop up when people naively use JWT to represent access tokens 🙈.

Please note: Even though this document and [RFC7523] both use JSON Web Tokens in the OAuth2 framework, they differ in both intent and mechanics 💀. [RFC7523] defines how a JWT Bearer Token can be used to request an access token. This document describes how to encode access tokens in JWT format 🫶.

1.1. Requirements Notation and Conventions 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅.

1.2. Terminology 🦋

JWT access token: An OAuth 2.0 access token encoded in JWT format that complies with the requirements in this specification ✨.

This spec uses the terms "access token", "refresh token", "authorization server", "resource server", "authorization endpoint", "authorization request", "authorization response", "token endpoint", "grant type", "access token request", "access token response", and "client", as defined by The OAuth 2.0 Authorization Framework [RFC6749] 🌸.

2. JWT Access Token Header and Data Structure 👑

2.1. Header 💜

JWT access tokens MUST be signed 🔥. JWT access tokens can use any signing algorithm, but using asymmetric cryptography is RECOMMENDED because it makes it easier for resource servers to get validation info (see Section 4) 🫶. JWT access tokens MUST NOT use "none" as the signing algorithm 💀. See Section 4 for more details 🦋.

Authorization servers and resource servers that conform to this spec MUST include RS256 (as defined in [RFC7518]) among their supported signature algorithms ✨.

This spec registers the "application/at+jwt" media type, which can be used to say that the content is a JWT access token 🎀. JWT access tokens MUST include this media type in the "typ" header parameter to clearly declare that the JWT is an access token that follows this profile 💖. Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is RECOMMENDED that the "application/" prefix be omitted 🌈. So the "typ" value SHOULD be "at+jwt" 🧚. See the Security Considerations section for details on why it matters to stop OpenID Connect ID Tokens (as defined by Section 2 of [OpenID.Core]) from being accepted as access tokens by resource servers implementing this profile 🙈.

2.2. Data Structure 🌸

The following claims are used in the JWT access token data structure ✨.

iss  REQUIRED - as defined in Section 4.1.1 of [RFC7519].

exp  REQUIRED - as defined in Section 4.1.4 of [RFC7519].

aud  REQUIRED - as defined in Section 4.1.3 of [RFC7519].  See
   Section 3 for indications on how an authorization server should
   determine the value of "aud" depending on the request.

sub  REQUIRED - as defined in Section 4.1.2 of [RFC7519].  In cases
   of access tokens obtained through grants where a resource owner is
   involved, such as the authorization code grant, the value of "sub"
   SHOULD correspond to the subject identifier of the resource owner.
   In cases of access tokens obtained through grants where no
   resource owner is involved, such as the client credentials grant,
   the value of "sub" SHOULD correspond to an identifier the
   authorization server uses to indicate the client application.  See
   Section 5 for more details on this scenario.  Also, see Section 6
   for a discussion about how different choices in assigning "sub"
   values can impact privacy.

client_id  REQUIRED - as defined in Section 4.3 of [RFC8693].

iat  REQUIRED - as defined in Section 4.1.6 of [RFC7519].  This claim
   identifies the time at which the JWT access token was issued.

jti  REQUIRED - as defined in Section 4.1.7 of [RFC7519].

Here's the vibe: iss, exp, aud, sub, client_id, iat, and jti are all REQUIRED 💅. Each one has its own rules in the list above, so read them closely, bestie 🙈.

2.2.1. Authentication Information Claims 🦋

The claims in this section MAY be issued in the context of authorization grants that involve the resource owner 💖. They reflect the types and strength of authentication that the authentication server enforced before returning the authorization response to the client ✨. Their values are fixed and stay the same across all access tokens that come from a given authorization response 🌈. That's true whether the access token was obtained directly in the response (for example, via the implicit flow) or after one or more token exchanges (for example, getting a fresh access token with a refresh token, or swapping one access token for another via [RFC8693] procedures) 🧚.

auth_time  OPTIONAL - as defined in Section 2 of [OpenID.Core].

acr  OPTIONAL - as defined in Section 2 of [OpenID.Core].

amr  OPTIONAL - as defined in Section 2 of [OpenID.Core].

Okay bestie, that's part 1 of 4 🎀. More is coming, so stay tuned for the rest of the RFC 💜✨.

2.2.2. Identity Claims 🪪

okay so, when a resource owner is part of the grant, commercial authorization servers will often just tuck resource owner attributes right into the access token 🎀 so resource servers can use them for authorization or whatever else, with no extra round trips to introspection ([RFC7662]) or UserInfo ([OpenID.Core]) endpoints. literally so efficient 😭 It's super common when the client and the resource server are the same entity and part of the same solution, like first-party clients calling their own backend API 💅

This profile doesn't add any way for a client to directly ask for specific claims in JWT access tokens 🙅‍♀️ Instead, the authorization server figures out which extra claims a resource server needs by looking at the client_id of the client, plus the scope and resource parameters in the request. the way that's so smart ✨

Any extra identity attribute whose meaning is well described by an entry in the "JSON Web Token (JWT)" IANA registry introduced in [RFC7519] SHOULD be encoded using that corresponding claim name, if it's going to be included in the JWT access token 🦋 fyi, the JWT IANA registry already includes the claims found in Section 5.1 of [OpenID.Core] 🧚

Authorization servers MAY return arbitrary attributes that aren't defined in any existing specification 🌈 as long as the claim names are collision resistant, or the access tokens are only meant to be used within a private subsystem. Check Sections 4.2 and 4.3 of [RFC7519] for the deets.

Bestie, if you're putting resource owner attributes in JWT access tokens, you need to be careful 🙈 and double-check that all the privacy requirements are met, like we talk about in Section 6.

2.2.3. Authorization Claims 🔑

If an authorization request includes a scope parameter, the JWT access token that gets issued SHOULD include a "scope" claim, as defined in Section 4.2 of [RFC8693] 💖

All the individual scope strings in the "scope" claim MUST have meaning for the resources indicated in the "aud" claim. See Section 5 for more considerations about how scope strings and the resources indicated by the "aud" claim relate to each other 👑

2.2.3.1. Claims for Authorization Outside of Delegation Scenarios 🌸

Lots of authorization servers stuff authorization attributes into the access tokens they issue that go beyond the delegated scenarios described by [RFC7519] 🍓 Typical examples are resource owner memberships in roles and groups that matter for the resource being accessed, entitlements given to the resource owner for the targeted resource that the authorization server knows about, and so on.

An authorization server that wants to include these 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 encode the claim values according to the guidance defined in [RFC7643] ✨ For example (non-normative!), a "groups" attribute can be found in Section 8.2 of [RFC7643]. No specific vocabulary is provided for "roles" and "entitlements" 🫶

Section 7.2.1 of this document has entries for registering the "groups", "roles", and "entitlements" attributes from [RFC7643] as claim types to be used in this profile 🦋

3. Requesting a JWT Access Token 🚀

An authorization server can issue a JWT access token in response to any authorization grant defined by [RFC6749], plus subsequent extensions meant to result in an access token 💜

If the request includes a "resource" parameter (as defined in [RFC8707]), the resulting JWT access token's "aud" claim SHOULD have the same value as the "resource" parameter in the request 🌈

Here's an example request, bestie:

GET /as/authorization.oauth2?response_type=code
        &client_id=s6BhdRkqt3
        &state=xyz
        &scope=openid%20profile%20reademail
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
        &resource=https%3A%2F%2Frs.example.com%2F HTTP/1.1
     Host: authorization-server.example.com

Figure 1: Authorization Request with Resource and Scope Parameters 📸

Once the code from the request above is redeemed, it results in a JWT access token in the form shown below 🎁

Header:

{"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"}

Claims:

{
  "iss": "https://authorization-server.example.com/",
  "sub": "5ba552d67",
  "aud":   "https://rs.example.com/",
  "exp": 1639528912,
  "iat": 1618354090,
  "jti" : "dbe39bf3a3ba4238a513f51d6e1691c4",
  "client_id": "s6BhdRkqt3",
  "scope": "openid profile reademail"
}

Figure 2: The Header and JWT Claims Set of a JWT Access Token 💅

The authorization server MUST NOT issue a JWT access token if the authorization granted by the token would be ambiguous 🙀 See Section 5 for more details about common cases that might lead to ambiguity, and strategies an authorization server can use to prevent them.

If the request does not include a "resource" parameter, the authorization server MUST use a default resource indicator in the "aud" claim. If a "scope" parameter is present in the request, the authorization server SHOULD use it to infer the value of the default resource indicator to be used in the "aud" claim. The mechanism through which scopes are associated with default resource indicator values is outside the scope of this specification. If the values in the "scope" parameter refer to different default resource indicator values, the authorization server SHOULD reject the request with "invalid_scope", as described in Section 4.1.2.1 of [RFC6749] 🙅‍♀️

4. Validating JWT Access Tokens 🛂

For the purpose of making validation data retrieval easier, it is RECOMMENDED here that authorization servers sign JWT access tokens with an asymmetric algorithm 🔐

Authorization servers SHOULD use OAuth 2.0 Authorization Server Metadata [RFC8414] to advertise their signing keys to resource servers via "jwks_uri", and which "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 methods 🫶

An authorization server MAY elect to use different keys to sign OpenID Connect ID Tokens and JWT access tokens 🦋 This specification doesn't provide a mechanism for identifying a specific key as the one used to sign JWT access tokens. An authorization server can sign JWT access tokens with any of the keys advertised via authorization server (AS) metadata or OpenID Connect discovery. See Section 5 for further guidance on security implications 🔥

Resource servers receiving a JWT access token MUST validate it in the following manner 🧐

  • The resource server MUST verify that the "typ" header value is "at+jwt" or "application/at+jwt", and reject tokens carrying any other value.
  • If the JWT access token is encrypted, decrypt it using the keys and algorithms that the resource server specified during registration. If encryption was negotiated with the authorization server at registration time and the incoming JWT access token is not encrypted, the resource server SHOULD reject it.
  • The issuer identifier for the authorization server (which is typically obtained during discovery) MUST exactly match the value of the "iss" claim.
  • The resource server MUST validate that the "aud" claim contains a resource indicator value corresponding to an identifier the resource server expects for itself. The JWT access token MUST be rejected if "aud" does not contain a resource indicator of the current resource server as a valid audience.
  • The resource server MUST validate the signature of all incoming JWT access tokens according to [RFC7515], using the algorithm specified in the JWT "alg" Header Parameter. The resource server MUST reject any JWT in which the value of "alg" is "none". The resource server MUST use the keys provided by the authorization server.
  • The current time MUST be before the time represented by the "exp" claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew ⏰

The resource server MUST handle errors as described in Section 3.1 of [RFC6750]. In particular, in case of any failure in the validation checks listed above, the authorization server response MUST include the error code "invalid_token". Please note that this requirement does not prevent JWT access tokens from using authentication schemes other than "Bearer" 💀

If the JWT access token includes authorization claims as described in Section 2.2.3, the resource server SHOULD use them in combination with any other contextual information available to determine whether the current call should be authorized or rejected ✨ Details about how a resource server performs those checks are beyond the scope of this profile specification 🌸

5. Security Considerations 🔐

Okay bestie, the JWT access token data layout here is giving major id_token vibes 👀. It's very similar to the id_token defined by [OpenID.Core]. The explicit typing this profile requires, which lines up with the recommendations in [RFC8725], is what helps the resource server tell JWT access tokens apart from OpenID Connect ID Tokens. Iconic, right? ✨

Authorization servers should stop clients from messing with the sub claim in ways that could confuse resource servers 😬. For example, if the authorization server uses the client_id as the sub value for access tokens issued through the client credentials grant, the authorization server should prevent clients from registering an arbitrary client_id value. Otherwise, a malicious client could pick the sub of a high-privilege resource owner and totally confuse any authorization logic on the resource server that relies on sub 💀. For more details, please refer to Section 4.14 of [OAuth2.Security.BestPractices].

To prevent cross-JWT confusion, authorization servers MUST use a distinct identifier as an aud claim value to uniquely identify access tokens issued by the same issuer for distinct resources. This is non-negotiable, bestie 🔥. For more details on cross-JWT confusion, please refer to Section 2.8 of [RFC8725].

Authorization servers should be extra careful when handling requests that might lead to ambiguous authorization grants 👀. For example, if a request includes multiple resource indicators, the authorization server should make sure that each scope string included in the resulting JWT access token, if any, can be unambiguously correlated to a specific resource among the ones listed in the aud claim. How to spot and fix this, and other ambiguous situations, is highly scenario dependent, so it's out of scope for this profile 🙈.

Authorization servers cannot rely on using different keys for signing OpenID Connect ID Tokens and JWT tokens as a way to protect against the fallout from a leaked key 🚨. Resource servers have no way of knowing which key should be used to validate JWT access tokens in particular, so they have to accept signatures made with any of the keys published in AS metadata or OpenID Connect discovery. That means an attacker only needs to compromise any one of the published keys to generate and sign JWTs that the resource server will accept as valid. Yikes, periodt 😭.

6. Privacy Considerations 🦋

Since JWT access tokens carry information by value, clients and potentially even end users can now directly peek inside the claims of unencrypted tokens 👀.

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), so any client logic that depends on reading the access token content would break with no way back. The OAuth 2.0 framework assumes that clients treat access tokens as opaque. Administrators of authorization servers should also keep in mind that clients can see the content of an access token. Whenever client access to that content causes privacy issues in a given scenario, the authorization server needs to take explicit steps to prevent them 🫶.

In scenarios where JWT access tokens are accessible to the end user, it should be checked whether the information can be accessed without privacy violations (for example, if an end user is simply accessing their own personal information), or whether steps must be taken to enforce confidentiality 🔒.

Possible measures to prevent leakage of information to clients and end users include: encrypting the access token, encrypting the sensitive claims, omitting the sensitive claims or not using this profile, and falling back on opaque access tokens 🧚.

In every scenario, the content of the JWT access token will eventually be accessible to the resource server 👀. It's important to evaluate whether the resource server actually got the proper entitlement to access any content received as claims. That could come from user consent in some form, policies and agreements with the organization running the authorization servers, and so on. For example, a user might not want to give a resource server information about any of the non-mandatory claims listed in Section 2 (and its subsections) 💅.

This profile requires the sub claim in every JWT access token, which lets resource servers use that information to correlate incoming requests with data stored locally for the authenticated principal 🎀. Correlating requests might be needed by design in many scenarios, but there are also scenarios where the authorization server might want to prevent correlation. The sub claim should be populated by authorization servers according to a privacy impact assessment. For instance, if a solution needs to prevent tracking of principal activities across multiple resource servers, the authorization server should make sure that JWT access tokens meant for different resource servers have distinct sub values that cannot be correlated even if the resource servers collude 🕵️‍♀️. Similarly, if a solution needs to stop a resource server from correlating the principal's activity within the resource itself, the authorization server should assign a different sub value for every JWT access token it issues. In turn, the client should get a new JWT access token for every call to the resource server, so the resource server receives different sub and jti values on every call, which prevents correlation between distinct requests 🌈.

7. IANA Considerations 📝

7.1. Media Type Registration

7.1.1. Registry Content

This section registers application/at+jwt, a new media type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838]. It can be used to indicate that the content is an access token encoded in JWT format 🍓.

Type name:  Application

Subtype name:  at+jwt

Required parameters:  N/A

Optional parameters:  N/A

Encoding considerations:  Binary; JWT values are encoded as a series
   of base64url-encoded values (with trailing '=' characters
   removed), some of which may be the empty string, separated by
   period ('.') characters.

Security considerations:  See the Security Considerations section of
   RFC 9068.

Interoperability considerations:  N/A

Published specification:  RFC 9068

Applications that use this media type:  Applications that access
   resource servers using OAuth 2.0 access tokens encoded in JWT
   format

Fragment identifier considerations:  N/A

Additional information:

   Magic number(s):  N/A
   File extension(s):  N/A
   Macintosh file type code(s):  N/A

Person & email address to contact for further information:
   Vittorio Bertocci <vittorio@auth0.com>

Intended usage:  COMMON

Restrictions on usage:  None

Author:  Vittorio Bertocci <vittorio@auth0.com>

Change controller:  IETF

Provisional registration?  No

7.2. Claims Registration

Section 2.2.3.1 of this specification refers to the attributes "roles", "groups", and "entitlements" defined in [RFC7643] to express authorization information in JWT access tokens. This section registers those attributes as claims in the "JSON Web Token (JWT)" IANA registry introduced in [RFC7519] 🏷️.

7.2.1. Registry Content

7.2.1.1. Roles

Claim Name:  roles
Claim Description:  Roles
Change Controller:  IETF
Specification Document(s):  Section 4.1.2 of [RFC7643] and
   Section 2.2.3.1 of RFC 9068

7.2.1.2. Groups

Claim Name:  groups
Claim Description:  Groups
Change Controller:  IETF
Specification Document(s):  Section 4.1.2 of [RFC7643] and
   Section 2.2.3.1 of RFC 9068

7.2.1.3. Entitlements

Claim Name:  entitlements
Claim Description:  Entitlements
Change Controller:  IETF
Specification Document(s):  Section 4.1.2 of [RFC7643] and
   Section 2.2.3.1 of RFC 9068

8. References 📚

8.1. Normative References

[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", November 2014, https://openid.net/specs/openid-connect-core-1_0.html.

[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 1", November 2014, https://openid.net/specs/openid-connect-discovery-1_0.html.

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, https://www.rfc-editor.org/info/rfc2046.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, https://www.rfc-editor.org/info/rfc6749.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, https://www.rfc-editor.org/info/rfc6838.

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, https://www.rfc-editor.org/info/rfc7515.

[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, https://www.rfc-editor.org/info/rfc7518.

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, https://www.rfc-editor.org/info/rfc7519.

[RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 2015, https://www.rfc-editor.org/info/rfc7643.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, https://www.rfc-editor.org/info/rfc8414.

[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, https://www.rfc-editor.org/info/rfc8693.

[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, https://www.rfc-editor.org/info/rfc8707.

[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, https://www.rfc-editor.org/info/rfc8725.

8.2. Informative References 🦋

Okay so these are the bonus reads, bestie. They're not required to implement the spec, but they're super helpful background 💅

[IANA.MediaTypes]: IANA, "Media Types", <https://www.iana.org/assignments/media-types/>.

[OAuth2.Security.BestPractices]: Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "OAuth 2.0 Security Best Current Practice", Work in Progress, Internet-Draft, draft-ietf-oauth-security-topics-18, 13 April 2021, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18.

[RFC6750]: Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, https://www.rfc-editor.org/info/rfc6750.

[RFC7523]: Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, https://www.rfc-editor.org/info/rfc7523.

[RFC7662]: Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, https://www.rfc-editor.org/info/rfc7662.

Acknowledgements 🫶

Big thank-yous to everyone who made this spec happen! ✨

The first batch of requirements came from looking at loads of real access tokens in JWT format that production systems were already issuing. Huge thanks to Dominick Baier (IdentityServer), Brian Campbell (Ping Identity), Daniel Dobalian (Microsoft), and Karl Guinness (Okta) for sharing sample tokens from their products and services 🎀 Brian Campbell and Filip Skokan gave early feedback that really shaped where the spec went 💜 This profile got talked through at length at the OAuth Security Workshop 2019, and a bunch of people threw in ideas and feedback there too. The author wants to shout out:

John Bradley, Brian Campbell, Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig, and everyone who actively joined in on the unconference discussions 🌸

Next, these folks gave useful feedback and insights on the drafts, both on the IETF OAuth 2.0 WG mailing list and at the 28th Internet Identity Workshop (IIW 28) 🔥

Dale Olds, George Fletcher, David Waite, Michael Engan, Mike Jones, Hans Zandbelt, Vladimir Dzhuvinov, Martin Schanzenbach, Aaron Parecki, Annabelle Richard Backman, Dick Hardt, Denis Pinkas, Benjamin Kaduk, Dominick Baier, Andrii Deinega, Mike Jones, and everyone who actively participated in the IIW 28 unconference discussions and the IETF OAuth 2.0 WG mailing list discussions 🧚

Thanks also to Roman Danyliw for the AD review, Joseph Salowey and Roni Even for the SECDIR and GENART reviews, and Francesca Palomini, Lars Eggert, Murray Kucherawy, Roberto Polli, Martin Duke, and Benjamin Kaduk for the IESG reviews. Literally a whole squad 👑

Author's Address 💖

Vittorio Bertocci

Auth0

Email: vittorio@auth0.com

📦 where this page comes from