This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
OAuth 2.0 Dynamic Client Registration Management Protocol
OAuth 2.0 Dynamic Client Registration Management Protocol

Version management

Difference between version and

At line 1 added 17 lines
!!! Overview
[{$pagename}] extended [OAuth 2.0 Dynamic Client Registration Protocol] with [REST]ful operations to permit retrieval (via [HTTP GET]), modification ([HTTP PUT]) and deletion ([HTTP DELETE]) of an [OAuth 2.0 Client Registration].
[{$pagename}] when it was an [Internet Draft] and was combined with [OpenID Connect Dynamic Client Registration] into [{$pagename}] 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|client_id]. 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|Certificate Validation], 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 5.1.4.2.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.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop