| Internet-Draft | OAuth Pushed Client Registration | April 2025 |
| Richer & Parecki | Expires 24 October 2025 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-richer-oauth-pushed-client-registration/.¶
Discussion of this document takes place on the WG Working Group mailing list (mailto:WG@example.com), which is archived at https://example.com/WG.¶
Source for this draft and an issue tracker can be found at https://github.com/USER/REPO.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 October 2025.¶
Copyright (c) 2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC7591] 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 [RFC9126], a Pushed Client Registration can enable open world protocols to use the OAuth family of protocols as their security layer.¶
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.¶
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 [RFC8792]. The \ character and leading spaces on wrapped lines are not part of the value.¶
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¶
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.¶
NOTE: '\' line wrapping per RFC 8792 POST /token HTTP/1.1 Host: as.example.com Content-type: application/www-form-urlencoded DPoP: eyj… DPoP-Key: ejy… client_id=urn:ietf:oauth:parameters:dynamic\ &code=98765cd-oe\ &grant_type=authorization_code\ &code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk¶
The AS processes the authorization code and issues an access token to the client.¶
NOTE: '\' line wrapping per RFC 8792
HTTP 200 OK
Content-Type: application/json
{
"access_token": "654edfgh-jkoiu789.0plkjhg34k",
"token_type": "DPoP"
}
¶
The client can then use this token to call the RS.¶
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.¶
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.¶
An AS supporting this extension that publishes its metadata using [RFC8414] MUST indicate its support by including the key:¶
A boolean value indicating that this specification is supported and accepted by the AS.¶
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.¶
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.¶