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 Client Registration
OAuth 2.0 Client Registration

Version management

Difference between version and

At line 1 added 53 lines
!!! 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-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop