RFC 9101

The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)

📅 published August 2021, from ietf

RFC 9101: The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) 💖

okay bestie, RFC 9101 is from the Internet Engineering Task Force (IETF) and it's dated August 2021 🍓. It's a Standards Track document, which means it's an actual Internet Standard and not just a suggestion 👑. The ISSN is 2070-1721. It was written by N. Sakimura of NAT.Consulting, J. Bradley of Yubico, and M. Jones of Microsoft, so it's a whole team of legends ✨. The title block has no "Obsoletes" or "Updates" line, so this doc doesn't list anything it obsoletes or updates.

Abstract ✨

The authorization request in OAuth 2.0, described in RFC 6749, uses query parameter serialization. That means the authorization request parameters get encoded in the URI of the request and sent through user agents like web browsers 🌐. It's super easy to implement, but it means that a) the communication through the user agents isn't integrity protected, so the parameters can be tainted, b) the source of the communication isn't authenticated, and c) the communication through the user agents can be monitored 👀. Because of these weaknesses, several attacks on the protocol have now been put forward 💀.

This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead 🦋. That lets the request get signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE), so the integrity, source authentication, and confidentiality properties of the authorization request are attained 🔒. The request can be sent by value or by reference 🧚.

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9101.

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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🦋

1.  Introduction
  1.1.  Requirements Language
2.  Terminology
  2.1.  Request Object
  2.2.  Request Object URI
3.  Symbols and Abbreviated Terms
4.  Request Object
5.  Authorization Request
  5.1.  Passing a Request Object by Value
  5.2.  Passing a Request Object by Reference
    5.2.1.  URI Referencing the Request Object
    5.2.2.  Request Using the "request_uri" Request Parameter
    5.2.3.  Authorization Server Fetches Request Object
6.  Validating JWT-Based Requests
  6.1.  JWE Encrypted Request Object
  6.2.  JWS-Signed Request Object
  6.3.  Request Parameter Assembly and Validation
7.  Authorization Server Response
8.  TLS Requirements
9.  IANA Considerations
  9.1.  OAuth Parameters Registration
  9.2.  OAuth Authorization Server Metadata Registry
  9.3.  OAuth Dynamic Client Registration Metadata Registry
  9.4.  Media Type Registration
    9.4.1.  Registry Contents
10. Security Considerations
  10.1.  Choice of Algorithms
  10.2.  Request Source Authentication
  10.3.  Explicit Endpoints
  10.4.  Risks Associated with request_uri
    10.4.1.  DDoS Attack on the Authorization Server
    10.4.2.  Request URI Rewrite
  10.5.  Downgrade Attack
  10.6.  TLS Security Considerations
  10.7.  Parameter Mismatches
  10.8.  Cross-JWT Confusion
11. Privacy Considerations
  11.1.  Collection Limitation
  11.2.  Disclosure Limitation
    11.2.1.  Request Disclosure
    11.2.2.  Tracking Using Request Object URI
12. References
  12.1.  Normative References
  12.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

The authorization request in OAuth 2.0 [RFC6749] uses query parameter serialization, and it's typically sent through user agents like web browsers 🌐.

For example, the parameters "response_type", "client_id", "state", and "redirect_uri" get encoded in the URI of the request:

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

It's easy to implement, but the encoding in the URI doesn't allow application-layer security to provide confidentiality and integrity protection 🙈. TLS is used to offer communication security between the client and the user agent, and between the user agent and the authorization server. But TLS sessions get terminated in the user agent. Also, TLS sessions may be terminated prematurely at some middlebox, such as a load balancer.

So the authorization request of [RFC6749] has shortcomings in that:

  • (a) the communication through the user agents is not integrity protected, and thus, the parameters can be tainted (integrity protection failure);
  • (b) the source of the communication is not authenticated (source authentication failure);
  • (c) the communication through the user agents can be monitored (containment/confidentiality failure).

Due to these inherent weaknesses, several attacks against the protocol, such as redirection URI rewriting, have been identified 💀.

Application-layer security mitigates these issues 🛡️.

Application-layer security also lets requests be prepared by a trusted third party, so a client application can't request more permissions than were previously agreed upon 💅.

Plus, passing the request by reference reduces over-the-wire overhead 📉.

The JWT [RFC7519] encoding was chosen because of:

  • (1) its close relationship with JSON, which is used as OAuth's response format;
  • (2) its developer friendliness due to its textual nature;
  • (3) its relative compactness compared to XML;
  • (4) its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516];
  • (5) the relative ease of JWS and JWE compared to XML Signature and Encryption.

The parameters "request" and "request_uri" are introduced as additional authorization request parameters for the OAuth 2.0 [RFC6749] flows. The "request" parameter is a JSON Web Token (JWT) [RFC7519] whose JWT Claims Set holds the JSON-encoded OAuth 2.0 authorization request parameters. Note that, unlike RFC 7519, the elements of the Claims Set are encoded OAuth request parameters [IANA.OAuth.Parameters], supplemented with only a few of the IANA-managed JSON Web Token Claims [IANA.JWT.Claims], in particular, "iss" and "aud". The JWT in the "request" parameter is integrity protected and source authenticated using JWS 🔐.

The JWT [RFC7519] can be passed to the authorization endpoint by reference, in which case the parameter "request_uri" is used instead of "request" 🧚.

Using JWT [RFC7519] as the request encoding instead of query parameters has several advantages:

  • (a) Integrity protection. The request can be signed so that the integrity of the request can be checked.
  • (b) Source authentication. The request can be signed so that the signer can be authenticated.
  • (c) Confidentiality protection. The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another (including at and before user agents).
  • (d) Collection minimization. The request can be signed by a trusted third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a trusted third party to confirm that all the personal data requested is strictly necessary to perform the process that the end user asked for; the request would then be signed by that trusted third party. The authorization server then examines the signature and shows the conformance status to the end user, who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances 🫶.

There are a few cases where request by reference is useful:

  1. When it is desirable to reduce the size of a transmitted request. The use of application-layer security increases the size of the request, particularly when public-key cryptography is used.
  2. When the client does not want to do the application-level cryptography. The authorization server may provide an endpoint to accept the authorization request through direct communication with the client, so that the client is authenticated and the channel is TLS protected.

This capability is in use by OpenID Connect [OpenID.Core] 🌈.

1.1. Requirements Language 🎀

Okay so 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], but only when they show up in all capitals, just like here 💅.

2. Terminology 🧚

For the purposes of this specification, the following terms and definitions apply in addition to what's defined in the OAuth 2.0 Framework [RFC6749], JSON Web Signature [RFC7515], and JSON Web Encryption [RFC7516] 📖.

2.1. Request Object 🍓

A Request Object is a JSON Web Token (JWT) [RFC7519] whose JWT Claims Set holds the JSON-encoded OAuth 2.0 authorization request parameters.

2.2. Request Object URI 🦋

A Request Object URI is an absolute URI that references the set of parameters comprising an OAuth 2.0 authorization request. The content of the resource referenced by the URI is a Request Object (Section 2.1), unless the URI was provided to the client by the same authorization server. In that case, the content is an implementation detail at the discretion of the authorization server.

The content being a Request Object is there to ensure interoperability in cases where the provider of the "request_uri" is a separate entity from the consumer. For example, a client provides a URI referencing a Request Object stored on the client's backend service, made accessible via HTTPS. In the latter case, where the authorization server is both provider and consumer of the URI, such as when it offers an endpoint that provides a URI in exchange for a Request Object, this interoperability concern doesn't apply 🙌.

3. Symbols and Abbreviated Terms 💜

The following abbreviations are common to this specification.

JSON:  JavaScript Object Notation

JWT:  JSON Web Token

JWS:  JSON Web Signature

JWE:  JSON Web Encryption

URI:  Uniform Resource Identifier

URL:  Uniform Resource Locator

4. Request Object ✨

okay so a Request Object (Section 2.1) is basically the bundle that carries all the authorization request parameters for an OAuth 2.0 authorization request 🎀 It MUST contain every parameter (extension parameters included) that's needed to process the OAuth 2.0 [RFC6749] request, except for the request and request_uri parameters, which this document defines. The parameters become the JWT Claims of the object, and parameter names and string values MUST be included as JSON strings. Since Request Objects get passed across domains and maybe outside a closed ecosystem (see Section 8.1 of [RFC8259]), those JSON strings MUST be encoded using UTF-8 [RFC3629] 🌸 Numerical values MUST be included as JSON numbers, and the Request Object MAY include any extension parameters. This JSON [RFC8259] object is the JWT Claims Set from [RFC7519], and then the Claims Set gets signed or signed and encrypted 💅

For signing, we use JWS [RFC7515], and the result is a JWS-signed JWT [RFC7519]. If it's signed, the Authorization Request Object SHOULD contain the iss (issuer) and aud (audience) Claims, with the same meaning they have in the JWT [RFC7519] spec. The value of aud should be the authorization server (AS) "issuer" from RFC 8414 [RFC8414] 🦋

For encryption, we use JWE [RFC7516]. When you're doing both signature and encryption, the JWT MUST be signed first and then encrypted, as described in Section 11.2 of [RFC7519]. That gives you a Nested JWT, as defined in [RFC7519] 🔥

The client picks the algorithms used to sign and encrypt Request Objects, but they need to be supported by both the client and the authorization server, no cap 🫶 The client can tell the authorization server what it supports through its dynamic client registration metadata [RFC7591], using the metadata values request_object_signing_alg, request_object_encryption_alg, and request_object_encryption_enc. And the authorization server can return the favour by listing what it supports in its authorization server metadata [RFC8414], using request_object_signing_alg_values_supported, request_object_encryption_alg_values_supported, and request_object_encryption_enc_values_supported 💜

The Request Object MAY be sent by value (Section 5.1) or by reference (Section 5.2). Either way, request and request_uri parameters MUST NOT be included in Request Objects, because that would be a whole mess 🙈

A Request Object (Section 2.1) has the media type "application/oauth-authz-req+jwt" [RFC2046]. Heads up that some existing deployments might be using "application/jwt" instead ✨

Here's an example of the Claims in a Request Object before base64url [RFC7515] encoding and signing. Notice it has the extension parameters nonce and max_age 🧚

{
 "iss": "s6BhdRkqt3",
 "aud": "https://server.example.com",
 "response_type": "code id_token",
 "client_id": "s6BhdRkqt3",
 "redirect_uri": "https://client.example.org/cb",
 "scope": "openid",
 "state": "af0ifjsldkj",
 "nonce": "n-0S6_WzA2Mj",
 "max_age": 86400
}

Signing that with the "RS256" algorithm [RFC7518] gives you this Request Object value (the line wraps are just for display purposes):

eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

To validate the Request Object signature in this example and the ones that follow, you can use this RSA public key, represented in JSON Web Key (JWK) format (again, line wraps are just for display):

{
 "kty":"RSA",
 "kid":"k2bdc",
 "n":"x5RbkAZkmpRxia65qRQ1wwSMSxQUnS7gcpVTV_cdHmfmG2ltd2yabEO9XadD8
      pJNZubINPpmgHh3J1aD9WRwS05ucmFq3CfFsluLt13_7oX5yDRSKX7poXmT_5
      ko8k4NJZPMAO8fPToDTH7kHYbONSE2FYa5GZ60CUsFhSonI-dcMDJ0Ary9lxI
      w5k2z4TAdARVWcS7sD07VhlMMshrwsPHBQgTatlkxyIHXbYdtak8fqvNAwr7O
      lVEvM_Ipf5OfmdB8Sd-wjzaBsyP4VhJKoi_qdgSzpC694XZeYPq45Sw-q51iF
      UlcOlTCI7z6jltUtnR6ySn6XDGFnzH5Fe5ypw",
 "e":"AQAB"
}

5. Authorization Request 💖

okay now the client builds the authorization request URI by adding these parameters to the query component of the authorization endpoint URI, using the "application/x-www-form-urlencoded" format 🌈

  • request: REQUIRED unless request_uri is specified. This is the Request Object (Section 2.1) holding the authorization request parameters from Section 4 of [RFC6749] (OAuth 2.0). If this parameter is in the authorization request, request_uri MUST NOT be present.
  • request_uri: REQUIRED unless request is specified. This is the absolute URI, as defined by RFC 3986 [RFC3986], that points to the Request Object URI (Section 2.2) with the authorization request parameters from Section 4 of [RFC6749] (OAuth 2.0). If this parameter is in the authorization request, request MUST NOT be present.
  • client_id: REQUIRED. This is the OAuth 2.0 [RFC6749] "client_id". Its value MUST match the client_id of the request or request_uri Request Object (Section 2.1).

Then the client sends the resource owner to the constructed URI, either with an HTTP redirection response or some other method the user agent makes available 🦋

For example, the client sends the end user's user agent to this HTTPS request:

GET /authz?client_id=s6BhdRkqt3&request=eyJhbG..AlMGzw HTTP/1.1
Host: server.example.com

The request value is shortened here for brevity, so don't panic 😭

The Authorization Request Object MUST be one of the following:

  • (a) JWS signed
  • (b) JWS signed and JWE encrypted

The client MAY send the parameters from the Request Object again as query parameters, for backward compatibility and things like that 🍓 However, an authorization server that supports this specification MUST only use the parameters included in the Request Object 👑

5.1. Passing a Request Object by Value 🎀

The client sends the authorization request as a Request Object to the authorization endpoint, as the value of the request parameter 💅

Here's an example of an authorization request using the request parameter (line wraps are for display only):

https://server.example.com/authorize?client_id=s6BhdRkqt3&
  request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJz
  NkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20i
  LAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50
  X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgICJz
  dGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1qIiwK
  ICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgKb5xsuZR
  VqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcn
  KZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDP
  dulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujF
  fzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa
  5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

5.2. Passing a Request Object by Reference 🦄

The request_uri authorization request parameter lets you pass OAuth authorization requests by reference instead of by value 🌸 It works exactly like the request parameter, except the Request Object value gets fetched from the resource at the URI you specify, rather than being sent along by value.

The entire Request URI SHOULD NOT exceed 512 ASCII characters. There are two reasons for this, and they're both very real:

  1. Lots of phones still don't accept big payloads. The limit is usually 512 or 1024 ASCII characters 📱
  2. On a slow connection, like 2G mobile, a huge URL makes the response slow, so it's not great for user experience 🐢

The contents of the resource referenced by request_uri MUST be a Request Object, and MUST be reachable by the authorization server unless the URI was given to the client by the authorization server 🔥 In the first case, request_uri MUST be an "https" URI, as specified in Section 2.7.2 of [RFC7230]. In the second case, it MUST be a URN, as specified in [RFC8141] ✨

Here's an example of what a Request Object resource referenced by request_uri could look like (line wraps for display only):

eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

5.2.1. URI Referencing the Request Object 🧚

The client stores the Request Object resource either locally or remotely, at a URI the authorization server can reach 💜 That facility might be run by the authorization server or by a trusted third party. For example, the authorization server could provide a URL where the client POSTs the Request Object and gets back the Request URI. That URI is the Request Object URI, request_uri 🫶

The Request Object might include values that should only be revealed to the authorization server, so the request_uri MUST have appropriate entropy for its lifetime. That way, if it's publicly retrievable, it can't just be guessed 🙈 For guidance, check out Section 5.1.4.2.2 of [RFC6819] and "Good Practices for Capability URLs" [CapURLs]. It is RECOMMENDED that the request_uri be removed after a reasonable timeout, unless access control measures are in place 🌈

Here's an example of a Request Object URI value (line wraps for display only). In this example, a trusted third-party service hosts the Request Object 🦋

https://tfp.example.org/request.jwt/
  GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

5.2.2. Request Using the "request_uri" Request Parameter

okay so this is the bit where the client actually sends the authorization request to the authorization endpoint 💌 🦋

Here's a little example of an authorization request using the "request_uri" parameter. The line wraps are only there so it's easier to read on screen, not part of the actual URL ✨

https://server.example.com/authorize?
  client_id=s6BhdRkqt3
  &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
  %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

5.2.3. Authorization Server Fetches Request Object

okay this part is giving server homework 🧚💅 when the authorization server gets the Request, it MUST send an HTTP "GET" request to the "request_uri" to grab the referenced Request Object. The only exception is if the Request Object is stored somewhere the server can securely retrieve it through other mechanisms and then parse it to rebuild the authorization request parameters 🫶

Here's an example of that fetch, where a trusted third-party service is hosting the Request Object 🌸

GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
Host: tfp.example.org

And this is what the fetch response looks like 👑

HTTP/1.1 200 OK
Date: Thu, 20 Aug 2020 23:52:39 GMT
Server: Apache/2.4.43 (tfp.example.org)
Content-type: application/oauth-authz-req+jwt
Content-Length: 797
Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT

eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

6. Validating JWT-Based Requests ✨

6.1. JWE Encrypted Request Object

okay so if the Request Object is encrypted, the authorization server MUST decrypt the JWT following the JSON Web Encryption [RFC7516] spec 🔐

The result is a signed Request Object 💖

And if decryption fails? The authorization server MUST return an invalid_request_object error to the client in response to the authorization request. Not me getting an error 💀

6.2. JWS-Signed Request Object

the authorization server MUST validate the signature of the JWS-signed [RFC7515] Request Object 🦋 If a kid Header Parameter is present, the key it identifies MUST be the key used, and MUST be a key associated with the client. The signature MUST be validated using a key associated with the client and the algorithm named in the alg Header Parameter. Algorithm verification MUST be performed, as specified in Sections 3.1 and 3.2 of [RFC8725]. main character energy for security 👑

If the key isn't associated with the client, or if signature validation fails, the authorization server MUST return an invalid_request_object error to the client in response to the authorization request. 🙈

6.3. Request Parameter Assembly and Validation

the authorization server MUST extract the set of authorization request parameters from the Request Object value. It MUST only use the parameters in the Request Object, even if the same parameter shows up in the query parameter 🍓 The client ID values in the client_id request parameter and in the Request Object client_id claim MUST be identical. Then the authorization server validates the request, as specified in OAuth 2.0 [RFC6749] 🌈

If the Client ID check or the request validation fails, the authorization server MUST return an error to the client in response to the authorization request, as specified in Section 5.2 of [RFC6749] (OAuth 2.0). 😭

7. Authorization Server Response ✨

The authorization server response is created and sent to the client as in Section 4 of [RFC6749] (OAuth 2.0) 🎀

Plus, this document uses these extra error values, and they're iconic:

  • invalid_request_uri: The "request_uri" in the authorization request returns an error or contains invalid data.
  • invalid_request_object: The request parameter contains an invalid Request Object.
  • request_not_supported: The authorization server does not support the use of the "request" parameter.
  • request_uri_not_supported: The authorization server does not support the use of the "request_uri" parameter.

8. TLS Requirements 🔒

client implementations that support the Request Object URI method MUST support TLS, following "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [RFC7525] 💜

To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a cipher suite that provides confidentiality and integrity protection. Security is not optional, bestie 💅

HTTP clients MUST also verify the TLS server certificate, using DNS-ID [RFC6125], to avoid man-in-the-middle attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations:

  • Support for the DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED. Certification authorities that issue server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in server certificates.
  • DNS names in server certificates MAY contain the wildcard character "*".
  • Clients MUST NOT use CN-ID identifiers. A Common Name field (CN field) may be present in the server certificate's subject name, but it MUST NOT be used for authentication within the rules described in [RFC7525] 🙅‍♀️
  • SRV-ID and URI-ID as described in Section 6.5 of [RFC6125] MUST NOT be used for comparison.

9. IANA Considerations 🌷

9.1. OAuth Parameters Registration

okay so the Request Object is a JWT, which means the core JWT claims can't be used for anything in the Request Object other than what JWT dictates. So they've been registered as OAuth authorization request parameters, so future OAuth extensions don't use them with different meanings 🧠✨

This specification adds the following values to the "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749]:

Name:  "iss"
Parameter Usage Location:  authorization request
Change Controller:  IETF
Specification Document(s):  This document and Section 4.1.1 of
   [RFC7519].

Name:  "sub"
Parameter Usage Location:  authorization request
Change Controller:  IETF
Specification Document(s):  This document and Section 4.1.2 of
   [RFC7519].

Name:  "aud"
Parameter Usage Location:  authorization request
Change Controller:  IETF
Specification Document(s):  This document and Section 4.1.3 of
   [RFC7519].

Name:  "exp"
Parameter Usage Location:  authorization request
Change Controller:  IETF
Specification Document(s):  This document and Section 4.1.4 of
   [RFC7519].

Name:  "nbf"
Parameter Usage Location:  authorization request
Change Controller:  IETF
Specification Document(s):  This document and Section 4.1.5 of
   [RFC7519].

Name:  "iat"
Parameter Usage Location:  authorization request
Change Controller:  IETF
Specification Document(s):  This document and Section 4.1.6 of
   [RFC7519].

Name:  "jti"
Parameter Usage Location:  authorization request
Change Controller:  IETF
Specification Document(s):  This document and Section 4.1.7 of
   [RFC7519].

9.2. OAuth Authorization Server Metadata Registry

This specification adds the following value to the "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414]:

Metadata Name:  "require_signed_request_object"
Metadata Description:  Indicates where authorization request needs to
   be protected as Request Object and provided through either
   "request" or "request_uri parameter".
Change Controller:  IETF
Specification Document(s):  Section 10.5 of this document.

9.3. OAuth Dynamic Client Registration Metadata Registry

This specification adds the following value to the "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]:

Metadata Name:  "require_signed_request_object"
Metadata Description:  Indicates where authorization request needs to
   be protected as Request Object and provided through either
   "request" or "request_uri parameter".
Change Controller:  IETF
Specification Document(s):  Section 10.5 of this document.

9.4. Media Type Registration

9.4.1. Registry Contents

this section registers the "application/oauth-authz-req+jwt" 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 a JWT containing Request Object claims 📮

Type name:  application
Subtype name:  oauth-authz-req+jwt
Required parameters:  N/A
Optional parameters:  N/A
Encoding considerations:  binary; a Request Object is a JWT; JWT
   values are encoded as a series of base64url-encoded values (some
   of which may be the empty string) separated by period (".")
   characters.
Security considerations:  See Section 10 of RFC 9101
Interoperability considerations:  N/A
Published specification:  Section 4 of RFC 9101
Applications that use this media type:  Applications that use Request
   Objects to make an OAuth 2.0 authorization request
Fragment identifier considerations:  N/A
Additional information:
   Deprecated alias names for this type:  N/A
   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:
   Nat Sakimura <nat@nat.consulting>
Intended usage:  COMMON
Restrictions on usage:  none
Author:  Nat Sakimura <nat@nat.consulting>
Change controller:  IETF
Provisional registration?  No

10. Security Considerations 🚨

okay this one is SERIOUS bestie 😭 In addition to all the security considerations discussed in OAuth 2.0 [RFC6819], the security considerations in [RFC7515], [RFC7516], [RFC7518], and [RFC8725] need to be considered. There are also several academic papers, such as [BASIN], that give useful insight into the security properties of protocols like OAuth 🎓

In consideration of the above, this document advises taking the following security considerations into account 💫

10.1. Choice of Algorithms

when the Authorization Request Object is sent through the "request" parameter, it MUST be either signed using JWS [RFC7515], or signed and then encrypted using JWS [RFC7515] and JWE [RFC7516], respectively, with algorithms considered appropriate at the time. Choose your algorithms wisely, periodt 🔐💅

10.2. Request Source Authentication 🔐

okay bestie, this one is SO important 😭 the source of the authorization request MUST always be verified, no exceptions, no cap. There are a few ways to do it:

  • (a) Verify the JWS Signature of the Request Object ✍️
  • (b) Verify that the symmetric key for the JWE encryption is the correct one, but only if the JWE is using symmetric encryption. Heads up though: if public key encryption is used, the encryption does NOT authenticate the source at all, because literally anyone can encrypt to a public key 💀
  • (c) Verify the TLS Server Identity of the Request Object URI. Here the authorization server MUST know out-of-band that the client uses the Request Object URI, and only the client is covered by the TLS certificate. Honestly this is not a reliable method in general 🙈
  • (d) When an authorization server runs a service that hands back a Request Object URI in exchange for a Request Object, the authorization server MUST perform client authentication before it accepts the Request Object and binds the client identifier to the Request Object URI it gives out. It MUST validate the signature, same as (a). Since a Request Object URI can get replayed, its lifetime MUST be short and preferably one-time use. Its entropy MUST be sufficiently large too 🔥. How short and how much entropy is "enough" depends on a risk calculation based on how valuable the protected resource is. As general guidance, the validity time should be less than a minute, and the Request Object URI should include a cryptographic random value of 128 bits or more, as of when this spec was written 🎀
  • (e) When a trusted third-party service returns a Request Object URI in exchange for a Request Object, it MUST validate the signature, same as (a). On top of that, the authorization server MUST be trusted by the third-party service, and it MUST know out-of-band that the client is also trusted by that service 🫶

10.3. Explicit Endpoints 🦋

Okay so this spec doesn't require it, but research like [BASIN] shows it's a good practice to explicitly state the intended interaction endpoints and the message position in the sequence in a tamper-evident way. That way the initiator's intent is unambiguous ✨. It is RECOMMENDED by this specification to do this for the following endpoints defined in [RFC6749], [RFC6750], and [RFC8414]:

  • (a) Protected resources ("protected_resources") 🌸
  • (b) Authorization endpoint ("authorization_endpoint") 🌸
  • (c) Redirection URI ("redirect_uri") 🌸
  • (d) Token endpoint ("token_endpoint") 🌸

And if dynamic discovery is used, this practice also applies to the discovery-related endpoints too 💅

Now the tea ☕: in [RFC6749], the redirection URI is included in the authorization request, but the others aren't. So the same thing applies to the Authorization Request Object 🧚

10.4. Risks Associated with request_uri 💀

The introduction of "request_uri" opens up several attack possibilities, not gonna lie 😭. If you want the full story on risks tied to URIs in general, check the security considerations in Section 7 of [RFC3986] 📚.

10.4.1. DDoS Attack on the Authorization Server 🚨

A group of malicious clients can launch a DoS attack on the authorization server by pointing "request_uri" at a URI that returns extremely large content or is extremely slow to respond. Under that kind of attack, the server might use up its resources and start failing 😩.

It's also sneaky: a malicious client can give a "request_uri" value that itself points to an authorization request URI which uses "request_uri", causing a recursive lookup 🌀.

To stop this attack from working, the server should a) check that the value of the "request_uri" parameter doesn't point to an unexpected location, b) check that the media type of the response is "application/oauth-authz-req+jwt", c) implement a timeout for fetching the content of "request_uri", and d) not perform a recursive GET on the "request_uri" 🛑.

10.4.2. Request URI Rewrite ✏️

The value of "request_uri" is not signed, which means a man-in-the-browser attacker can tamper with it 👀. This opens up a few attacks. For example, a) an attacker might create another file for the rewritten URI to point to, so the request gets extra scope, or b) an attacker might launch a DoS attack on a victim site by setting "request_uri" to point at the victim 😤.

To stop this from working, the server should a) check that the value of the "request_uri" parameter doesn't point to an unexpected location, b) check that the media type of the response is "application/oauth-authz-req+jwt", and c) implement a timeout for fetching the content of "request_uri" ⏱️.

10.5. Downgrade Attack 📉

Unless the protocol used by the client and server is locked down to use an OAuth JWT-Secured Authorization Request (JAR), an attacker can use RFC 6749 requests to bypass ALL the protection this spec provides 💀. Not it!

To prevent this, the spec defines new client metadata and server metadata values, both named "require_signed_request_object", and both are booleans 🔒.

When its value as client metadata is "true", the server MUST reject any authorization request from a client that doesn't conform to this spec. It MUST also reject the request if the Request Object uses an "alg" value of "none" while this server metadata value is "true". If it's omitted, the default is "false" 🙅‍♀️.

When its value as server metadata is "true", the server MUST reject any authorization request from any client that doesn't conform to this spec. It MUST also reject the request if the Request Object uses an "alg" value of "none". If it's omitted, the default is "false" ✨.

Also, even if the "require_signed_request_object" metadata values aren't present, the client MAY use signed Request Objects, as long as the client and server support a common signing algorithm. Use of signing algorithm metadata is described in Section 4 🧾.

10.6. TLS Security Considerations 🔐

The current security considerations live in "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [RFC7525] 📖. That one supersedes the TLS version recommendations in OAuth 2.0 [RFC6749] 💜.

10.7. Parameter Mismatches 🙈

OAuth parameter values get sent in two places: as normal OAuth parameters AND as Request Object claims. So implementations must guard against attacks that use mismatched parameter values to get unintended outcomes 😱. That's why the two client ID values MUST match, why only the parameter values from the Request Object are used, and why neither "request" nor "request_uri" can appear in a Request Object 🛡️.

10.8. Cross-JWT Confusion 🌀

As described in Section 2.8 of [RFC8725], attackers may try to use a JWT that was issued for one purpose in a context it wasn't meant for 👻. The mitigations for these attacks can be applied to Request Objects too 💅.

One way an attacker might try to repurpose a Request Object is to use it as a client authentication JWT, as described in Section 2.2 of [RFC7523]. An easy fix is to never use the client ID as the "sub" value in a Request Object 🫶.

Another way to prevent cross-JWT confusion is explicit typing, as described in Section 3.11 of [RFC8725]. You explicitly type a Request Object by including a "typ" Header Parameter with the value "oauth-authz-req+jwt" (which is registered in Section 9.4.1) 🏷️. Heads up though: requiring explicitly typed Request Objects at existing authorization servers will break most existing deployments, because existing clients already commonly use untyped Request Objects, especially with OpenID Connect [OpenID.Core] 😬. However, requiring explicit typing would be a good idea for new OAuth deployment profiles where compatibility with existing deployments isn't a concern 🌈.

Finally, another way to stop cross-JWT confusion is a key management regime where the keys used to sign Request Objects are identifiably distinct from those used for anything else. Then, if an adversary tries to repurpose a Request Object in another context, a key mismatch happens and the attack gets thwarted 🧚‍♀️.

11. Privacy Considerations 🦋

When the client is being granted access to a protected resource containing personal data, BOTH the client and the authorization server need to adhere to Privacy Principles 🔒. "Privacy Considerations for Internet Protocols" [RFC6973] gives excellent guidance on improving protocol design and implementation, and the provisions listed in it should be followed ✨.

Most of those provisions would apply to "The OAuth 2.0 Authorization Framework" [RFC6749] and "The OAuth 2.0 Authorization Framework: Bearer Token Usage" [RFC6750], and they aren't specific to this spec. So below, we only note the provisions that ARE specific to this spec 💅.

11.1. Collection Limitation 🧺

When the client is being granted access to a protected resource containing personal data, the client SHOULD limit the collection of personal data to what's within the bounds of applicable law and strictly necessary for the specified purpose(s) 🌷.

It's often hard for the user to figure out whether the personal data being asked for is strictly necessary 🥺. A trusted third-party service can help by examining the client request, comparing it to the client's proposed processing, and certifying the request. After certification, the client can submit an authorization request to that trusted third-party service to get a Request Object URI 🎀. This happens in two steps:

  1. (Certification Process) The trusted third-party service examines the client's business process and figures out what claims they need. That's the certification process 📋. Once the client is certified, it gets issued a client credential to authenticate with, so it can push Request Objects to the trusted third-party service and get a "request_uri" 🔑.
  2. (Translation Process) The client uses the client credential it got to push the Request Object to the trusted third-party service and get a "request_uri". The trusted third-party service also verifies that the Request Object is consistent with the claims the client is eligible for, based on the previous step 🔍.

When the authorization server gets a Request Object URI in the authorization request, it first verifies that the authority portion of the Request Object URI is a legit one for the trusted third-party service 🕵️‍♀️. Then the authorization server issues an HTTP GET request to the Request Object URI. Upon connecting, the authorization server MUST verify that the server identity in the TLS certificate is legitimate for the Request Object URI 🔐. After that, it can obtain the Request Object, which includes the "client_id" representing the client 🫶.

The Consent screen MUST indicate the client and SHOULD indicate that the request has been vetted by the trusted third-party service for adherence to the collection limitation principle 💖✨

11.2. Disclosure Limitation 🎀

11.2.1. Request Disclosure ✨

okay so bestie, this spec lets you add extension parameters 👀, and those can totally carry potentially sensitive info 😭. Query params are kinda leaky, because they can slip out through referrers and browser history 💀. So if the authorization request has a potentially sensitive parameter, the client SHOULD encrypt the Request Object using JWE [RFC7516] 🔐💅.

Where the Request Object URI method is being used 🌸, if the Request Object has personally identifiable or sensitive info, the "request_uri" SHOULD be used only once and have a short validity period, and it MUST have sufficient entropy for the applicable security policies unless the Request Object itself is encrypted using JWE [RFC7516] 🙈. How short "short" is and how much entropy you need depends on a risk calculation based on how valuable the protected resource is 💎. General guidance for validity is less than a minute ⏱️, and the Request Object URI is to include a cryptographic random value of 128 bits or more at the time of the writing of this specification 🧚.

11.2.2. Tracking Using Request Object URI 🕵️‍♀️

Even if the protected resource doesn't include personally identifiable information, it's sometimes possible to identify the user through the Request Object URI if persistent static per-user Request Object URIs are used. A third party may observe it through browser history, etc. and start correlating the user's activity using it. In a way, it's a data disclosure as well and should be avoided 😩.

Therefore, per-user persistent Request Object URIs should be avoided. Single-use Request Object URIs are one alternative 🦋.

12. References 📚

12.1. Normative References

[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>.

[RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
           10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
           2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66,
           RFC 3986, DOI 10.17487/RFC3986, January 2005,
           <https://www.rfc-editor.org/info/rfc3986>.

[RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
           Verification of Domain-Based Application Service Identity
           within Internet Public Key Infrastructure Using X.509
           (PKIX) Certificates in the Context of Transport Layer
           Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
           2011, <https://www.rfc-editor.org/info/rfc6125>.

[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>.

[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>.

[RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
           Protocol (HTTP/1.1): Message Syntax and Routing",
           RFC 7230, DOI 10.17487/RFC7230, June 2014,
           <https://www.rfc-editor.org/info/rfc7230>.

[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>.

[RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
           RFC 7516, DOI 10.17487/RFC7516, May 2015,
           <https://www.rfc-editor.org/info/rfc7516>.

[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>.

[RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
           "Recommendations for Secure Use of Transport Layer
           Security (TLS) and Datagram Transport Layer Security
           (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
           2015, <https://www.rfc-editor.org/info/rfc7525>.

[RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
           (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
           <https://www.rfc-editor.org/info/rfc8141>.

[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>.

[RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
           Interchange Format", STD 90, RFC 8259,
           DOI 10.17487/RFC8259, December 2017,
           <https://www.rfc-editor.org/info/rfc8259>.

[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>.

12.2. Informative References

[BASIN]    Basin, D., Cremers, C., and S. Meier, "Provably Repairing
           the ISO/IEC 9798 Standard for Entity Authentication",
           Journal of Computer Security - Security and Trust
           Principles, Volume 21, Issue 6, pp. 817-846, November
           2013,
           <https://www.cs.ox.ac.uk/people/cas.cremers/downloads/
           papers/BCM2012-iso9798.pdf>.

[CapURLs]  Tennison, J., Ed., "Good Practices for Capability URLs",
           W3C First Public Working Draft, 18 February 2014,
           <https://www.w3.org/TR/capability-urls/>.

[IANA.JWT.Claims]
           IANA, "JSON Web Token (JWT)",
           <https://www.iana.org/assignments/jwt>.

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

[IANA.OAuth.Parameters]
           IANA, "OAuth Parameters",
           <https://www.iana.org/assignments/oauth-parameters>.

[OpenID.Core]
           Sakimura, N., Bradley, J., Jones, M.B., de Medeiros, B.,
           and C. Mortimore, "OpenID Connect Core 1.0 incorporating
           errata set 1", OpenID Foundation Standards, 8 November
           2014,
           <http://openid.net/specs/openid-connect-core-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>.

[RFC6819]  Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
           Threat Model and Security Considerations", RFC 6819,
           DOI 10.17487/RFC6819, January 2013,
           <https://www.rfc-editor.org/info/rfc6819>.

[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>.

[RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
           Morris, J., Hansen, M., and R. Smith, "Privacy
           Considerations for Internet Protocols", RFC 6973,
           DOI 10.17487/RFC6973, July 2013,
           <https://www.rfc-editor.org/info/rfc6973>.

[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>.

[RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
           P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
           RFC 7591, DOI 10.17487/RFC7591, July 2015,
           <https://www.rfc-editor.org/info/rfc7591>.

[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>.

Acknowledgements 🫶

Huge shoutout to everyone who helped build this in the OAuth Working Group and other IETF roles. Affiliations are the ones they had at the time of their contribution, and they're giving legends 👑.

The following people contributed to the creation of this document in the OAuth Working Group and other IETF roles. (Affiliations at the time of the contribution are used.)

Annabelle Backman (Amazon), Dirk Balfanz (Google), Sergey Beryozkin, Ben Campbell (as AD), Brian Campbell (Ping Identity), Roman Danyliw (as AD), Martin Duke (as AD), Vladimir Dzhuvinov (Connect2id), Lars Eggert (as AD), Joel Halpern (as GENART), Benjamin Kaduk (as AD), Stephen Kent (as SECDIR), Murray Kucherawy (as AD), Warren Kumari (as OPSDIR), Watson Ladd (as SECDIR), Torsten Lodderstedt (yes.com), Jim Manico, James H. Manger (Telstra), Kathleen Moriarty (as AD), Axel Nennker (Deutsche Telecom), John Panzer (Google), Francesca Palombini (as AD), David Recordon (Facebook), Marius Scurtescu (Google), Luke Shepard (Facebook), Filip Skokan (Auth0), Hannes Tschofenig (ARM), Éric Vyncke (as AD), and Robert Wilton (as AD).

The following people contributed to creating this document through the OpenID Connect Core 1.0 [OpenID.Core].

Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou (Mixi), Edmund Jay (Illumila), Breno de Medeiros (Google), Hideki Nara (TACT), and Justin Richer (MITRE).

Authors' Addresses 💌

Nat Sakimura
NAT.Consulting
2-22-17 Naka
Kunitachi, Tokyo 186-0004
Japan

Phone: +81-42-580-7401
Email: nat@nat.consulting
URI:   https://nat.sakimura.org/


John Bradley
Yubico
Sucursal Talagante
Casilla 177
Talagante
RM
Chile

Phone: +1.202.630.5272
Email: rfc9101@ve7jtb.com
URI:   http://www.thread-safe.com/


Michael B. Jones
Microsoft
One Microsoft Way
Redmond, Washington 98052
United States of America

Email: mbj@microsoft.com
URI:   https://self-issued.info/
📦 where this page comes from