Advanced Identity Cloud as authorization server

As an authorization server, PingOne Advanced 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.

OAuth 2.0 concepts

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:

Table 1. OAuth 2.0 framework actors
Actor	Description
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.
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. PingOne Advanced 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. PingOne Advanced 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:

Figure 1. OAuth 2.0 protocol flow

To use PingOne Advanced Identity Cloud as an authorization server, register an OAuth 2.0 application (client) in the Advanced Identity Cloud admin UI. Clients can also register themselves dynamically.

Supported OAuth 2.0 features

As an authorization server, PingOne Advanced Identity Cloud supports the following features:

Table 2. OAuth 2.0 features
Feature	Details
Grant types	Authorization code Implicit Resource owner password credentials Client credentials Device flow SAML 2.0 profile for authorization grant JWT profile for OAuth 2.0 authorization grants
Client authentication standards	JWT profile for OAuth 2.0 client authentication Mutual TLS
Other OAuth 2.0 standards	JWT proof-of-possession OpenID Connect
Remote consent services	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. PingOne Advanced Identity Cloud can grant scopes statically or dynamically: Statically (default) Configure several OAuth 2.0 clients with different subsets of scopes. Resource owners are redirected to a specific client, depending on the scopes required. As long as the resource owner can authenticate and the client can deliver the same or a subset of the requested scopes, PingOne Advanced Identity Cloud issues the token with the scopes requested. Two different users requesting scopes A and B from the same client will always receive scopes A and B. Dynamically Configure an OAuth 2.0 client with a comprehensive list of scopes. Resource owners authenticate against that client. When PingOne Advanced Identity Cloud receives a request for scopes, the authorization service grants or denies access scopes dynamically by evaluating authorization policies. Two different users requesting scopes A and B from the same client can receive different scopes, based on policy conditions. For details, refer to Authorization and policy decisions and Dynamic OAuth 2.0 authorization.

Security considerations

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.