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.

OAuth 2.0 Client Registration is typically a one-time task. Once registered, the registration remains valid, unless the OAuth Client registration is revoked.

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

OAuth 2.0 Client Registration 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, OAuth 2.0 Client Registration can also be Manual or Dynamic:

OAuth 2.0 Client Registration 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 Client Registration and Native applications#

OAuth 2.0 for Native Apps (RFC 8252) Section 8.4 specifies OAuth 2.0 Client Registration 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. At a minimum, any private URI Scheme that doesn't contain a period character (".") SHOULD be rejected.

In addition to the collision-resistant 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). 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:
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop