Access Management 7.2.2

AM as the authorization server

In the role of the authorization server, AM authenticates resource owners and obtains their authorization in order to return access tokens to clients.

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), either on behalf of the resource owner or the application.

The main actors in the OAuth 2.0 authorization framework are the following:

OAuth 2.0 Framework Actors
Actor Description

Resource Owner (RO)

The owner of the resources. For example, a user that has several photos stored 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 obtain access to the resources. 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.

AM 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 during a limited amount of time.

AM 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:

OAuth 2.0 protocol flow
Figure 1. OAuth 2.0 protocol flow

Before configuring OAuth 2.0 in your environment, ensure you are familiar with the OAuth 2.0 authorization framework and the RFCs, Internet-Drafts, and standards that AM supports relating to OAuth 2.0.

When using AM as the authorization server, you can register confidential or public clients in the AM admin UI, or clients can register themselves with AM dynamically. For more information, see Client registration.

As the authorization server, AM supports the following:

Grant types

  • Authorization Code

  • Implicit

  • Resource Owner Password Credentials

  • Client Credentials

  • Device Flow

  • SAML v2.0 Profile for Authorization Grant

  • JWT Profile for OAuth 2.0 Authorization Grants

For more information, see OAuth 2.0 grant flows.

Client authentication standards

  • JWT profile for OAuth 2.0 client authentication

  • Mutual TLS

For more information, see OAuth 2.0 client authentication.

Token exchange standards
Other OAuth 2.0 standards

See the complete list with links to RFCs and Internet drafts.

Moreover, AM as an authorization server supports the following capabilities:

  • Remote consent services, which allows the consent-gathering part of an OAuth 2.0 flow to be handed off to a separate service.

    For more information, see Remote consent.

  • Dynamic scopes, which allows customization of how scopes are granted to the client regardless of the grant flow used. You can configure AM to grant scopes statically or dynamically:

    • Statically (Default). You configure several OAuth 2.0 clients with different subsets of scopes and 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, AM issues the token with the scopes requested. Therefore, two different users requesting scopes A and B to the same client will always receive scopes A and B.

    • Dynamically. You configure an OAuth 2.0 client with a comprehensive list of scopes and resource owners authenticate against it. When AM receives a request for scopes, AM’s authorization service grants or denies access scopes dynamically by evaluating authorization policies at runtime. Therefore, two different users requesting scopes A and B to the same client can receive different scopes based on policy conditions.

    For more information about granting scopes dynamically, see 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. Therefore, do not let an attacker capture requests or responses. Protect the messages going across the network.

RFC 6749 includes a number of Security Considerations, and also requires transport layer security (TLS) to protect sensitive messages. Make sure you read the section covering Security Considerations, and that you can implement them in your deployment.

Also, especially when deploying a mix of other clients and resource servers, take into account the points covered in OAuth 2.0 Threat Model and Security Considerations, before putting your service into production.

OAuth 2.0 sample mobile applications

To try the capabilities of AM as an authorization server, you can download the sample mobile application.

For access to the source code, see How do I access and build the sample code provided for PingAM? in the Knowledge Base.