Overview#OAuth 2.0 Dynamic Client Registration Management Protocol extended OAuth 2.0 Dynamic Client Registration Protocol with RESTful operations to permit retrieval (via HTTP GET), modification (HTTP PUT) and deletion (HTTP DELETE) of an OAuth 2.0 Client Registration.
OAuth 2.0 Dynamic Client Registration Management Protocol when it was an Internet Draft and was combined with OpenID Connect Dynamic Client Registration into OAuth 2.0 Dynamic Client Registration Management Protocol as RFC 7592.
Security Considerations#While the client secret can expire, the Registration Access Token SHOULD NOT expire while a OAuth Client is still actively registered.
If this Registration Access Token were to expire, a developer or OAuth Client could be left in a situation where they have no means of retrieving, updating, or deleting the OAuth Client's registration information. Were that the case, a new registration would be required, thereby generating a new client identifier. However, to limit the exposure surface of the Registration Access Token, the Registration Access Token MAY be rotated when the developer or OAuth Client does a read or update operation on the OAuth Client's client configuration endpoint. As the Registration Access Tokens are relatively long-term credentials, and since the Registration Access Token is a Bearer Token and acts as the sole authentication for use at the client configuration endpoint, it MUST be protected by the developer or OAuth Client as described in the OAuth 2.0 Bearer Token Usage specification RFC 6750.
Since requests to the client configuration endpoint result in the transmission of clear-text credentials (in the HTTP request and response), 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 (RFC 5246) and MAY support additional transport-layer security mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS/SSL server certificate check, per RFC 6125. Implementation security considerations can be found in Recommendations for Secure Use of TLS and DTLS BCP195.
Since possession of the Registration Access Token authorizes the holder to potentially read, modify, or delete a client's registration (including its credentials such as a client_secret), the Registration Access Token MUST contain sufficient entropy to prevent a random guessing attack of the Registration Access Token, such as described in Section 5.2 of RFC 6750 and Section 126.96.36.199.2 of RFC 6819.
If a OAuth Client is deprovisioned from a server, any outstanding Registration Access Token for that OAuth Client MUST be invalidated at the same time. Otherwise, this can lead to an inconsistent state wherein a OAuth Client could make requests to the client configuration endpoint where the authentication would succeed but the action would fail because the OAuth Client is no longer valid. The authorization Server MUST treat all such requests as if the Registration Access Token was invalid by returning an HTTP 401 Unauthorized error, as described.