Identity Cloud as authorization server
As an authorization server, Identity Cloud authenticates resource owners and obtains their authorization to return access tokens to clients.
Before you configure OAuth 2.0 in your environment, familiarize yourself with the OAuth 2.0 authorization framework and related standards.
RFC 6749, the OAuth 2.0 authorization framework lets a third-party application obtain limited access to a resource (usually user data) on behalf of the resource owner or the application itself.
The main actors in the OAuth 2.0 authorization framework are the following:
Resource owner (RO)
The owner of the resource. For example, a user who stores their photos in a photo-sharing service.
The resource owner uses a user-agent, usually a web-browser, to communicate with the client.
The third-party application that wants to access the resource. The client makes requests on behalf of the resource owner and with their authorization. For example, a printing service that needs to access the resource owner’s photos to print them.
Identity Cloud can act as a client.
Authorization server (AS)
The authorization service that authenticates the resource owner and/or the client, issues access tokens to the client, and tracks their validity. Access tokens prove that the resource owner authorizes the client to act on their behalf over specific resources for a limited period of time.
Identity Cloud can act as the authorization server.
Resource server (RS)
The service hosting the protected resources. For example, a photo-sharing service. The resource server must be able to validate the tokens issued by the authorization server.
A website protected by a web or a Java agent can act as the resource server.
The following sequence diagram demonstrates the basic OAuth 2.0 flow:
To use Identity Cloud as an authorization server, register an OAuth 2.0 application (client) in the Identity Cloud admin UI. Clients can also register themselves dynamically.
As an authorization server, Identity Cloud supports the following features:
Other OAuth 2.0 standards
Delegates the consent-gathering part of an OAuth 2.0 flow to a separate service.
Customizable scope grants
You can customize how scopes are granted to the client, regardless of the grant flow used.
Identity Cloud can grant scopes statically or dynamically:
|OAuth 2.0 messages involve credentials and access tokens that allow the bearer to retrieve protected resources. You must protect the messages going across the network and prevent attackers from capturing requests or responses.
RFC 6749 includes a number of security considerations and requires Transport Layer Security (TLS) to protect sensitive messages. Make sure you read these security considerations and implement them in your deployment.
When you are deploying a combination of other clients and resource servers, pay special attention to the OAuth 2.0 threat model and security considerations before putting your service into production.