RFC 7592
OAuth 2.0 Dynamic Client Registration Management Protocol
RFC 7592: OAuth 2.0 Dynamic Client Registration Management Protocol 🎀
Okay bestie, the header tea ☕ This is RFC 7592, dated July 2015 📅. It's an Experimental doc 🧪, with ISSN 2070-1721. The authors are J. Richer (Ed.), M. Jones (Microsoft), J. Bradley (Ping Identity), and M. Machulak (Newcastle University) 🫶. The header doesn't list anything it obsoletes or updates, so there's nothing to chase there ✨.
Abstract 🌸
So this spec is all about managing OAuth 2.0 dynamic client registrations 💅 for when a registered client's properties need to change during the client's lifetime. Heads up: not every authorization server that supports dynamic client registration will support these management methods 👀.
Status of This Memo 📜
Real talk: this document is not an Internet Standards Track specification 🙅♀️. It's published for examination, experimental implementation, and evaluation.
It defines an Experimental Protocol for the Internet community 🧪. It's a product of the Internet Engineering Task Force (IETF), it represents IETF community consensus, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full picture 🤓.
For the current status of this document, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc7592 🔗.
Copyright Notice ©️
Copyright (c) 2015 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, which you can find at http://trustee.ietf.org/license-info as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty, as described in the Simplified BSD License ⚖️.
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4
2. Client Configuration Endpoint . . . . . . . . . . . . . . . . 5
2.1. Client Read Request . . . . . . . . . . . . . . . . . . . 6
2.2. Client Update Request . . . . . . . . . . . . . . . . . . 7
2.3. Client Delete Request . . . . . . . . . . . . . . . . . . 9
3. Client Information Response . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Registration Tokens and Client Credentials . . . . . 15
A.1. Credential Rotation . . . . . . . . . . . . . . . . . . . 16
Appendix B. Forming the Client Configuration Endpoint URL . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 181. Introduction ✨
Okay so, for an OAuth 2.0 client to use an OAuth 2.0 authorization server, it needs specific info to talk to that server, including an OAuth 2.0 client identifier 🪪. "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] explains how a client can be dynamically registered with an authorization server to get that info, and how the client's metadata can be registered with the server 💖.
This spec extends the core registration spec by defining methods for managing dynamic OAuth 2.0 client registrations, on top of what the core spec already covers 🧚. Sometimes a client's registered metadata changes over time, either because the authorization server modifies it or because the client software itself changes 🔄. So this spec gives you methods to query a client's current registration state at the authorization server, methods to update a client's registration there, and methods to unregister the client from the authorization server 🫧.
This Experimental RFC is meant to encourage building and deploying interoperable solutions, and the feedback from that experience will inform a future standard 🌈.
1.1. Notational Conventions
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [RFC2119] 🤓.
Unless otherwise noted, all the protocol parameter names and values are case sensitive 🔠.
1.2. Terminology
This spec uses the terms "access token", "authorization code", "authorization endpoint", "authorization grant", "authorization server", "client", "client identifier", "client secret", "grant type", "protected resource", "redirection URI", "refresh token", "resource owner", "resource server", "response type", and "token endpoint" as defined by OAuth 2.0 [RFC6749]. It also uses the terms defined by "OAuth 2.0 Client Dynamic Registration Protocol" [RFC7591] 📖.
It defines these terms too:
- Client Configuration Endpoint: OAuth 2.0 endpoint where registration info for a registered client can be managed. The authorization server returns this endpoint's URL in the client information response.
- Registration Access Token: OAuth 2.0 Bearer Token that the authorization server issues through the client registration endpoint. It authenticates the caller when they access the client's registration info at the client configuration endpoint. This access token is tied to one particular registered client 🔑.
1.3. Protocol Flow
This extends the flow in "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] like so 🌊:
+--------(A)- Initial Access Token (OPTIONAL)
|
| +----(B)- Software Statement (OPTIONAL)
| |
v v
+-----------+ +---------------+
| |--(C)- Client Registration Request -->| Client |
| | | Registration |
| |<-(D)- Client Information Response ---| Endpoint |
| | +---------------+
| |
| | +---------------+
| Client or |--(E)- Read or Update Request ------->| |
| Developer | | |
| |<-(F)- Client Information Response ---| Client |
| | | Configuration |
| | | Endpoint |
| | | |
| |--(G)- Delete Request --------------->| |
| | | |
| |<-(H)- Delete Confirmation -----------| |
+-----------+ +---------------+Figure 1: Abstract Extended Dynamic Client Registration Flow
Figure 1 shows the abstract OAuth 2.0 client dynamic registration flow, which is the interaction between the client or developer and the endpoints defined in this spec and its parent 🧩. The figure doesn't show error conditions. The flow goes like this:
- (A) Optionally, the client or developer gets an initial access token for use with the client registration endpoint. How that token gets issued is out of scope for this spec 🎟️.
- (B) Optionally, the client or developer gets a software statement for use with the client registration endpoint. How that statement gets issued is also out of scope for this spec 📝.
- (C) The client or developer calls the client registration endpoint with its desired registration metadata. It can optionally include the initial access token from (A), if the authorization server requires one 📨.
- (D) The authorization server registers the client and returns:
- the client's registered metadata,
- a client identifier that's unique to the server,
- a set of client credentials, such as a client secret, if that applies to this client,
- a URI pointing to the client configuration endpoint, and
- a registration access token to use when calling the client configuration endpoint 🎉.
- (E) The client or developer can optionally call the client configuration endpoint with a read or update request, using the registration access token from (D). An update request contains all of the client's registered metadata ✏️.
- (F) The authorization server responds with the client's current configuration. That can include a new registration access token and a new set of client credentials, such as a client secret, if that applies to this client. If a new registration access token is issued, it replaces the token from (D) for all later calls to the client configuration endpoint 🔁.
- (G) The client or developer can optionally call the client configuration endpoint with a delete request, using the registration access token from (D) or (F) 🗑️.
- (H) The authorization server deprovisions the client and responds with a confirmation that the deletion happened ✅.
2. Client Configuration Endpoint 🏠
The client configuration endpoint is an OAuth 2.0 protected resource that the server sets up so clients can view, update, and delete their registered info 💅. The client learns where this endpoint lives from the registration_client_uri member of the client information response, as covered in Section 3. The client MUST use its registration access token in all calls to this endpoint, as an OAuth 2.0 Bearer Token [RFC6750] 🔐.
The client configuration endpoint MUST be protected by a transport-layer security mechanism, as described in Section 5 🛡️.
Operations on this endpoint are chosen by using different HTTP methods [RFC7231] 🌷. If an authorization server doesn't support a particular method on the client configuration endpoint, it MUST respond with the appropriate error code 🙈.
2.1. Client Read Request 🔍✨
Okay so, if a client wants to see its current settings on the authorization server, it sends an HTTP GET request to the client configuration endpoint and authenticates with its registration access token 🎀
Here's a non-normative example request 💅:
GET /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483If the server successfully reads the info for a client that's still active, it replies with HTTP 200 OK, a content type of "application/json", and a payload described in Section 3 🥰 Some values in that response, like the "client_secret" and "registration_access_token", MAY be different from the ones in the initial registration response. If the server sends back a new client secret and/or registration access token, the client MUST immediately throw out its old client secret and/or registration access token 🗑️ The "client_id" MUST NOT change from what the initial registration response gave you.
If the registration access token used in this request isn't valid, the server MUST respond with an error as described in the OAuth Bearer Token Usage specification [RFC6750] 🚫
If the client doesn't exist on this server, the server MUST respond with HTTP 401 Unauthorized, and the registration access token used in this request SHOULD be immediately revoked 💀
If the client doesn't have permission to read its record, the server MUST return an HTTP 403 Forbidden 🙈
2.2. Client Update Request ✏️🌸
Next up, updating! To change a previously registered client's registration with an authorization server, the client sends an HTTP PUT request to the client configuration endpoint with a content type of "application/json" 💖 The HTTP entity payload is a JSON [RFC7159] document, which is a JSON object with all the parameters as top-level members of that object. This request is authenticated with the registration access token that was issued to the client 🔐
This request MUST include all the client metadata fields that were returned to the client from a previous registration, read, or update operation. The updated client metadata fields in the request MUST NOT include the "registration_access_token", "registration_client_uri", "client_secret_expires_at", or "client_id_issued_at" fields described in Section 3, because those are not for the client to send 🙅♀️
Valid values of client metadata fields in this request MUST replace the values previously associated with this client, not add to them. This is a full swap, bestie 🔄 Omitted fields MUST be treated by the server as null or empty values, which means the client is asking to delete them from its registration 🧹 The authorization server MAY ignore any null or empty value in the request, just like any other value.
The client MUST include its "client_id" field in the request, and it MUST be the same as its currently issued client identifier. If the client includes the "client_secret" field in the request, the value of that field MUST match the currently issued client secret for that client. The client MUST NOT be allowed to overwrite its existing client secret with a value it picked itself 🔒 No rewriting your own secret, periodt 💅
For all metadata fields, the authorization server MAY replace any invalid values with suitable default values, and it MUST return any such fields to the client in the response ✨
Here's an example of how a client could send a request to the client registration endpoint to update the registration from the example above with new info 🎀
Here's a non-normative example request 💖:
PUT /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
{
"client_id": "s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/alt"],
"grant_types": ["authorization_code", "refresh_token"],
"token_endpoint_auth_method": "client_secret_basic",
"jwks_uri": "https://client.example.org/my_public_keys.jwks",
"client_name": "My New Example",
"client_name#fr": "Mon Nouvel Exemple",
"logo_uri": "https://client.example.org/newlogo.png",
"logo_uri#fr": "https://client.example.org/fr/newlogo.png"
}
This example uses client metadata values defined in [RFC7591] 📚
If the update works, the server replies with HTTP 200 OK, a content type of "application/json", and a payload described in Section 3 🎉 Some values in the response, like the "client_secret" and "registration_access_token", MAY be different from the ones in the initial registration response. If the server sends back a new client secret and/or registration access token, the client MUST immediately throw out its old client secret and/or registration access token 🗑️ The "client_id" MUST NOT change from what the initial registration response gave you.
If the registration access token used in this request isn't valid, the server MUST respond with an error as described in the OAuth Bearer Token Usage specification [RFC6750] 🚫
If the client doesn't exist on this server, the server MUST respond with HTTP 401 Unauthorized, and the registration access token used in this request SHOULD be immediately revoked 💀
If the client isn't allowed to update its records, the server MUST respond with HTTP 403 Forbidden 🙈
If the client tries to set an invalid metadata field and the authorization server doesn't set a default value, the authorization server responds with an error as described in [RFC7591] 😭
2.3. Client Delete Request 🗑️💀
Last one in this group: deprovisioning! To remove itself from the authorization server, the client sends an HTTP DELETE request to the client configuration endpoint. This request is authenticated with the registration access token issued to the client 🔐
Here's a non-normative example request 🧚:
DELETE /register/s6BhdRkqt3 HTTP/1.1
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483A successful delete will invalidate the "client_id", "client_secret", and "registration_access_token" for this client, so the "client_id" can't be used at either the authorization endpoint or the token endpoint of the authorization server anymore 🚫✨ If possible, the authorization server SHOULD immediately invalidate all existing authorization grants, currently active access tokens, all refresh tokens, and all other tokens associated with this client 💅
If a client has been successfully deprovisioned, the authorization server MUST respond with an HTTP 204 No Content message 🍓
If the server doesn't support the delete method, the server MUST respond with HTTP 405 Not Supported 🙅♀️
If the registration access token used in this request isn't valid, the server MUST respond with an error as described in the OAuth Bearer Token Usage specification [RFC6750] 🚫
If the client doesn't exist on this server, the server MUST respond with HTTP 401 Unauthorized, and the registration access token used in this request SHOULD be immediately revoked, if possible 💀
If the client isn't allowed to delete itself, the server MUST respond with HTTP 403 Forbidden 🙈
Here's a non-normative example response 💜:
HTTP/1.1 204 No Content
Cache-Control: no-store
Pragma: no-cache3. Client Information Response 🎀📦
This spec extends the client information response defined in "OAuth 2.0 Client Dynamic Registration" [RFC7591], which says the response contains the client identifier (and the client secret too, if the client is a confidential client). When this spec is in play, the client information response also includes the fully qualified URL of the client configuration endpoint (Section 2) for this specific client. The client or developer can use that URL to manage the client's registration configuration 🛠️ It also includes a registration access token, which the client or developer uses for later operations at the client configuration endpoint 🔑
registration_client_uri REQUIRED. String containing the fully qualified URL of the client configuration endpoint for this client.
registration_access_token REQUIRED. String containing the access token to be used at the client configuration endpoint to perform subsequent operations upon the client registration.
On top of that, the authorization server MUST return all registered metadata about this client, including any fields the authorization server provisioned itself 📋 The authorization server MAY reject or replace any of the client's requested metadata values submitted during the registration or update requests, and substitute them with suitable values 🔄
The response is an "application/json" document with all parameters as top-level members of a JSON object [RFC7159] 💖
Here's a non-normative example response 🌈:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"registration_access_token": "reg-23410913-abewfq.123483",
"registration_client_uri":
"https://server.example.com/register/s6BhdRkqt3",
"client_id": "s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"client_id_issued_at": 2893256800,
"client_secret_expires_at": 2893276800,
"client_name": "My Example Client",
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/callback2"],
"grant_types": ["authorization_code", "refresh_token"],
"token_endpoint_auth_method": "client_secret_basic",
"logo_uri": "https://client.example.org/logo.png",
"jwks_uri": "https://client.example.org/my_public_keys.jwks"
}
4. IANA Considerations 🏛️📝
This spec registers the following client metadata names and descriptions in the "OAuth Dynamic Client Registration Metadata" registry that [RFC7591] set up:
- Client Metadata Name:
"registration_access_token" - Client Metadata Description: OAuth 2.0 Bearer Token used to access the client configuration endpoint
- Change Controller: IESG
- Specification Document(s): RFC 7592
- Client Metadata Name:
"registration_client_uri" - Client Metadata Description: Fully qualified URI of the client registration endpoint
- Change Controller: IESG
- Specification Document(s): RFC 7592
5. Security Considerations 🔐
Okay bestie, security time, and I'm not sugarcoating it 💀 The client secret is allowed to expire, but the registration access token SHOULD NOT expire while the client is still actively registered 🔒. If it did, the developer or client would be totally locked out with no way to retrieve, update, or delete the registration info. The only fix would be a brand new registration, which means a brand new client identifier 😭. To keep the exposure surface small, though, the registration access token MAY be rotated whenever the developer or client does a read or update operation on the client configuration endpoint 🔄.
The registration access token is a long-term credential and a Bearer Token, and it's the only authentication for the client configuration endpoint, so it MUST be protected by the developer or client as described in the OAuth 2.0 Bearer Token Usage specification [RFC6750] 🛡️.
Requests to the client configuration endpoint send clear-text credentials in both the HTTP request and the response, so the authorization server MUST require the use of a transport-layer security mechanism when sending requests to the endpoint. The server MUST support TLS 1.2 [RFC5246] and MAY support additional transport-layer security mechanisms that meet its security requirements. When using TLS, the client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. Implementation security considerations can be found in Recommendations for Secure Use of TLS and DTLS [BCP195] 🔐✨.
Possession of the registration access token lets the holder potentially read, modify, or delete a client's registration, including its credentials such as a client_secret. That means the registration access token MUST contain sufficient entropy to prevent a random guessing attack, as described in Section 5.2 of [RFC6750] and Section 5.1.4.2.2 of [RFC6819] 🎲.
⚠️ Deprovisioning alert! If a client is deprovisioned from a server, any outstanding registration access token for that client MUST be invalidated at the same time.
If that doesn't happen, things get messy: a client could keep making requests to the client configuration endpoint where authentication succeeds but the action fails because the client isn't valid anymore 🙈. So the authorization server MUST treat all such requests as if the registration access token was invalid, returning an HTTP 401 Unauthorized error, as described.
6. Privacy Considerations 🫣
Good news: this spec adds no extra privacy considerations beyond the ones in the core "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] 🌸.
7. Normative References 📚
Here's the full squad of references, with all the details 💅:
[BCP195] 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, May 2015,
<http://www.rfc-editor.org/info/bcp195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[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, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://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,
<http://www.rfc-editor.org/info/rfc6750>.
[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,
<http://www.rfc-editor.org/info/rfc6819>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[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,
<http://www.rfc-editor.org/info/rfc7591>.Appendix A. Registration Tokens and Client Credentials 🗝️
Throughout the dynamic registration protocol, there are three different classes of credentials in play, each with its own properties and targets 💜.
- The initial access token is optionally used by the client or developer at the registration endpoint. It's an OAuth 2.0 token used to authorize the initial client registration request. The content, structure, generation, and validation of this token are out of scope for this specification. The authorization server can use this token to verify that the presenter is allowed to dynamically register new clients. This token may be shared among multiple instances of a client so each one can register separately, which lets the authorization server tie multiple registered client instances (each with their own distinct client identifier) back to the party the initial access token was issued to, usually an application developer 🧑💻. This token is usually intended to be used only at the client registration endpoint.
- The registration access token is used by the client or developer at the client configuration endpoint, and it represents the holder's authorization to manage a client's registration 🔑. It's an OAuth 2.0 Bearer Token issued from the client registration endpoint in response to a client registration request, and it's returned in a client information response. The registration access token is uniquely bound to the client identifier and is required to be presented with all calls to the client configuration endpoint. It should be protected as described in [RFC6750] and should not be shared between instances of a client. If a registration access token is shared between client instances, one instance could change or delete registration values for all the other instances 😬. The registration access token can be rotated through the client read or update method on the client configuration endpoint. It is intended to be used only at the client configuration endpoint.
- The client credentials (such as
client_secret) are optional depending on the type of client, and they're used to retrieve OAuth tokens 🪪. Client credentials are most often bound to particular instances of a client and should not be shared between instances. Since not all types of clients have client credentials, they cannot be used to manage client registrations at the client configuration endpoint. The client credentials can be rotated through the client read or update method on the client configuration endpoint. They are intended to be used only at the token endpoint.
A.1. Credential Rotation 🔄
The authorization server may be configured to issue new registration access tokens and/or client credentials (such as a client_secret) throughout the lifetime of the client. This can help minimize the impact of exposed credentials 🛡️. The authorization server gives new registration access tokens and client credentials (if applicable) to the client in the client information response to either a read or update request on the client configuration endpoint. The client's current registration access token and client credentials (if applicable) MUST be included in the client information response.
The registration access token SHOULD be rotated only in response to a read or update request to the client configuration endpoint. At that point, the new registration access token is returned to the client, the old registration access token MUST be discarded by the client, and it SHOULD be discarded by the server, if possible. If the registration access token were instead to expire or be invalidated outside of those requests, the client or developer might get locked out of managing the client's configuration 🔐.
Note that the authorization server decides how often credential rotation happens, not the client. Methods by which the client can request credential rotation are outside the scope of this document.
Appendix B. Forming the Client Configuration Endpoint URL 🧚
The authorization server MUST provide the client with the fully qualified URL in the registration_client_uri element of the Client Information Response, as specified in Section 3. The authorization server MUST NOT expect the client to construct or discover this URL on its own. The client MUST use the URL as given by the server and MUST NOT construct this URL from component pieces 🙅♀️.
The client configuration endpoint URL may take any number of forms depending on deployment characteristics. It is RECOMMENDED that this endpoint URL be formed by a server-constructed URL string that combines the client registration endpoint's URL with the issued client_id for this client, with the client_id as either a path parameter or a query parameter 🌈. For example, a client with the client identifier "s6BhdRkqt3" could be given a client configuration endpoint URL of https://server.example.com/register/s6BhdRkqt3 (path parameter) or of https://server.example.com/register?client_id=s6BhdRkqt3 (query parameter). In both of these cases, the client simply uses the URL as given by the authorization server ✨.
These common patterns can help the server more easily determine which client a request pertains to, and that MUST be matched against the client to which the registration access token was issued. If desired, the server MAY simply return the client registration endpoint URL as the client configuration endpoint URL and change its behavior based on the authentication context provided by the registration access token 🦋.
Acknowledgments 🙏✨
okay so the authors gave a huge shoutout to the OAuth Working Group, the User-Managed Access Working Group, and the OpenID Connect Working Group 🫶 bestie, that's a LOT of people who helped make this happen. They say all these participants gave input to the document. Then they call out some people who were especially instrumental in reviewing and contributing to the different draft versions: Amanda Anganes, Derek Atkins, Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov, George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat Sakimura, Christian Scholz, and Hannes Tschofenig 👑 the way these names are literally the reason this spec slaps 💅
Authors' Addresses 💌
here's who wrote it, bestie 🎀 Justin Richer is the editor, and the others are Michael B. Jones, John Bradley, and Maciej Machulak. Their contact details are below, exactly as they appear in the original:
Justin Richer (editor)
Email: ietf@justin.richer.org
Michael B. Jones
Microsoft
Email: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley
Ping Identity
Email: ve7jtb@ve7jtb.com
Maciej Machulak
Newcastle University
Email: maciej.machulak@gmail.com📦 where this page comes from
- ietf: rfc7592 2015-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms