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

Version management

Difference between version and

At line 1 added 19 lines
!!! Overview
[{$pagename}] is described within [RFC 7591]
In order for an [OAuth 2.0] [RFC 6749] [client|OAuth Client] to utilize an [OAuth 2.0] [Authorization Server], the [OAuth Client] needs specific information to interact with the server, including an [OAuth 2.0] [Client_id] to use at that [Authorization Server].
!! Dynamic [OAuth 2.0 Client Registration]
The [specification|RFC 7591] describes how an [OAuth Client] can be dynamically registered with an authorization server to obtain this information.
As part of the registration process, this specification also defines a mechanism for the [client|OAuth Client] to present the [Authorization Server] with a set of metadata, such as a set of valid redirection URIs. This metadata can either be communicated in a self-asserted fashion or as a set of metadata called a software statement, which is digitally signed or MACed; in the case of a software statement, the issuer is vouching for the validity of the data about the [client|OAuth Client].
Traditionally, registration of a [client|OAuth Client] with an [Authorization Server] is performed manually. The mechanisms defined in this specification can be used either for a [client|OAuth Client] to dynamically register itself with authorization servers or for a client developer to programmatically register the [client|OAuth Client] with [Authorization Servers].
Multiple applications using [OAuth 2.0] have previously developed mechanisms for accomplishing such registrations. This specification generalizes the registration mechanisms defined by the [OpenID Connect] Dynamic Client Registration 1.0 [OpenID.Registration] specification and used by the [User Managed Access|User-Managed Access] (UMA) Profile of [OAuth 2.0] [I-D.hardjono-oauth-umacore] specification in a way that is compatible with both, while being applicable to a wider set of [OAuth 2.0] [use cases].
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [draft-ietf-oauth-dyn-reg-29|https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29|target='_blank'] - based on data observed:2015-05-18