!!! Overview
[OAuth Clients] must register with the [Authorization Server] before any transactions may occur.

Before an [OAuth Client] can request access to [Protected Resource] on a [Resource Server], the [OAuth Client] must first register with the [Authorization Server] associated with the [Resource Server].

[{$pagename}] is typically a one-time task. Once registered, the registration remains valid, unless the [OAuth Client] registration is revoked.

At [{$pagename}] the [OAuth Client] is assigned a [Client_id] and a [Client Secret] (password) by the [Authorization Server]. 

The [Client_id] and [Client Secret] is unique to the [OAuth Client] on that [Authorization Server]. 

If a [OAuth Client] registers with multiple [Authorization Servers] (e.g. both Facebook, Twitter and Google), each [Authorization Server] will probably issue a different and unique [Client ID|Client_id] to the [OAuth Client] application.

Whenever the [OAuth Client] requests access to resources stored on that same [Resource Server], the [OAuth Client] needs to [Authenticate] itself by sending the [Client ID|Client_id] and the [Client Secret] to the [Authorization Server].

During the registration the [OAuth Client] also registers a [redirect_uri]. This [redirect_uri] is used when a [Resource Owner] grants [Authorization] to the [OAuth Client]. When a [Resource Owner] has successfully Authorized the [OAuth Client] via the [Authorization Server], the [Resource Owner] is redirected back to the [OAuth Client]'s [redirect_uri].

[{$pagename}] must be done outside of the [The OAuth 2.0 Authorization Framework].

!! Open or managed registration
Access to the client registration endpoint can be open or managed:
* Open registration — Registration is open to all [OAuth Clients]. This is intended for [social Login] providers as well as for [Identity Provider (IDP)s] and services that are set up for automatic discovery. Requests should be rate limited to prevent DoS attacks.
* Managed registration — An initial [OAuth 2.0] [Access Token] is __required__ for registration. The [Access Token] is issued after the client application has passed an approval or screening process.

!! Manual or Dynamic
In addition to Open or Managed, [{$pagename}] can also be Manual or Dynamic:
* Manual - Most [Authorization Server] implementations provide a method from a GUI console.
* [OAuth 2.0 Dynamic Client Registration Protocol]

!! [{$pagename}] specs[1]
The importance of having a standard server endpoint for client registration was recognised early on by the WGs behind [OAuth 2.0] and [OpenID Connect]. They have published the following documents to address this:
* [OAuth 2.0 Dynamic Client Registration Protocol]
* [OAuth 2.0 Dynamic Client Registration Management Protocol] — extends the above spec with [REST]ful operations to permit retrieval (via [HTTP GET]), modification ([HTTP PUT]) and deletion ([HTTP DELETE]) of an OAuth 2.0 client registration.
* [OpenID Connect Dynamic Client Registration] — specifies additional metadata for [OAuth 2.0] clients that are [OpenID Connect] clients.

!! [{$pagename}] and [Native applications]
[OAuth 2.0 for Native Apps] ([RFC 8252]) Section 8.4 specifies [{$pagename}] of [Native applications] for  [Security Considerations]

Except when using a mechanism like [OAuth 2.0 Dynamic Client Registration Protocol] ([RFC 7591]) to provision per-instance secrets, native apps are classified as [OAuth Public Clients], as defined by Section 2.1 of [OAuth 2.0] ([RFC 6749]); they [MUST] be registered with the [Authorization Server] as such.  [Authorization Servers] [MUST] record the client type in the [OAuth 2.0 Dynamic Client Registration Protocol] details in order to identify and process requests accordingly.

[Authorization Servers] [MUST] require clients to register their complete [redirect_uri] (including the [URI Path] component) and reject [Authorization Requests] that specify a [redirect_uri] that doesn't exactly match the one that was registered; the exception is [loopback URI Redirection], where an exact match is required except for the [port] [URI] component.

For [private URI Scheme]-based redirects, [Authorization Servers] [SHOULD] enforce the requirement in Section 7.1 that clients use schemes that are [reverse domain name based|Reverse domain name notation].  At a minimum, any [private URI Scheme] that doesn't contain a period character (".") [SHOULD] be rejected.

In addition to the [collision-resistant|Collision-Resistant Name] properties, requiring a [URI Scheme] based on a [DNS Domain] name that is under the control of the app can help to prove ownership in the event of a dispute where two apps claim the same [Private URI Scheme] (where one app is acting [maliciously|Mallory]).  For [example], if two apps claimed "com.example.app", the owner of "[example.com]" could petition the app store operator to remove the counterfeit app.  Such a petition is harder to prove if a generic URI scheme was used.

[Authorization Servers] [MAY] request the inclusion of other platform-specific information, such as the app package or bundle name, or other information that may be useful for verifying the calling app's identity on [Operating Systems] that support such functions.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [OAuth 2.0 / OpenID Connect client registration explained|http://connect2id.com/blog/oauth-openid-connect-client-registration-explained/|target='_blank'] - based on information obtained 2016-07-01-