]> Bespoke Engineering

ietf@justin.richer.org https://bspk.io/

Okta

aaron@parecki.com https://aaronparecki.com

SEC WG Working Group oauth client registration This specification provides a way for an ephemeral or transactional OAuth 2.0 client to signal to the AS that the client does not need or expect to have an identified state outside the existence of any issued access and refresh tokens. The specification also enables a client to push its registration information to the AS during a pushed authorization request. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The OAuth protocol family was originally designed around a model of two relatively stable web sites connecting to each other's APIs on behalf of a user. This design, coupled with the need to begin transactions through an in-browser redirect in the authorization code and implicit grant types, leads naturally to an identifier for the client that can be presented in the front channel and referenced in the back channel along with client authentication. The client identifier could uniquely identify the client at the AS and be used to set policy and track its requests over time. Not all clients are sufficiently stable or monolithic to fit this model well. To compensate, OAuth 2.0 introduced the concept of "public clients", whereby many instances of a client (such as a native application or single-page browser application) would share a single identifier. OAuth Dynamic Client Registration enabled client software that did not get a client identifier at configuration time to obtain an identifier at runtime through a separate request to the AS. This enables dynamic configuration, but comes at a cost of needing to securely manage issuing and tracking these additional identifiers. Some forms of client software in open ecosystem patterns, such as the Model Context Protocol or many legacy software authentication systems like IMAP, are built around a different model whereby any compliant piece of client software should be able to connect to a compliant server, without a managed preregistration. For these clients, this specification defines a mechanism to indicate to the AS that a client does not need a longstanding identifier but instead desires authorization within a single delegation transaction. By using OAuth Pushed Authorization Requests , a Pushed Client Registration can enable open world protocols to use the OAuth family of protocols as their security layer.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. This document contains non-normative examples of partial and complete HTTP messages. Some examples use a single trailing backslash () to indicate line wrapping for long values, as per . The \ character and leading spaces on wrapped lines are not part of the value.

Protocol Flow Use of this specification consists of the following steps:

• The client makes a pushed authorization request using a defined static client_id value
• The AS returns a request_uri which the AS can associate to the specific request
• The client makes an authorization request using the request_uri
• The AS processes the authorization request based on the parameters pushed during the pushed authorization request
• The AS creates and returns an authorization code to the client
• The client submits the authorization code to the AS, again using the static client_id value

Pushed Authorization Request and Response The client MUST start the transaction using a pushed authorization request per . The request MUST include a client_id value of urn:ietf:oauth:parameters:dynamic. The request MUST include a state value and consist of a random number. The request MUST include a redirect_urivalue. The request MUST include an OAuth PKCE request per . The request MAY include a client_registration field, which consists of a form-encoded serialization of the JSON client metadata document defined in . Where the value of `client_registration_ is the form-encoded JSON value: If the client intends to use a sender-contstrained OAuth access token, such as via DPoP or mTLS , the client MUST send the bound authentication parameters appropriate to the method to the PAR endpoint, as in the above example. The AS creates a pending authorization request and associates it with an internal identifier, which it returns as a URN to the client:

Authorization Request and Response The client takes the result of the pushed authorization request and uses it to create an authorization request to the AS. The client MUST NOT include any parameters other than the syntactically required client_id, which is set to the static value in . The AS parses the value of the request_uri parameter and associates the incoming request with the values saved during the call to the PAR endpoint. When the AS has received appropriate authorization from the RO, the details of which are out of scope of this specification, the AS returns an authorization code to the client, along with its initial state value. When the client receives this request, the client compares the value of state to the stored state value to ensure they are equal to the one the client is expecting.

Toiken Request and Response The client takes the authorization code and sends it to the AS in exchange for a token. In this example, the client is requesting a DPoP bound access token. The AS processes the authorization code and issues an access token to the client. The client can then use this token to call the RS.

Token Expiration and Refresh The AS MAY issue a refresh token to the client, which can be used to get a new access token with the exact access rights of the original request. When the access token expires and the client has no valid refresh token, the client MUST create a new pushed authorization request to get a new token.

Client Identifier The client MUST use a client_id value of urn:ietf:oauth:parameters:dynamic in all requests. When receiving a client_id value of urn:ietf:oauth:parameters:dynamic, the AS MUST process it according to this specification. An AS MUST NOT assign the value urn:ietf:oauth:parameters:dynamic to any single client registration.

Discoverable Support An AS supporting this extension that publishes its metadata using MUST indicate its support by including the key:

"pushed_client_registration_supported":

A boolean value indicating that this specification is supported and accepted by the AS.

Security Considerations Support for this specification does not imply that it is supported for all possible access requests. In fact, an AS would be expected to determine through policy and configuration whether the request being made is suitable for a pushed client.

IANA Considerations

• Register the "dynamic" value in the IETF OAuth URN namespace
• register the "client_registration" authorization parameter
• extend the parameters table to indicate that a parameter can only be used inside a PAR request?
• register the AS metadata key

Normative References This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments The authors would like to thank Darin McAdams, Den Delimarsky, David Soria Perra, Adrian Frei, Pieter Kasselman, Jerome Swannack, Basil Hosmer, and Fei Yuan for their discussion and input to the concepts behind this draft.