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.
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 in the application's own behalf.
The main actors in the OAuth 2.0 authorization framework are the following:
| 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:
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 console, 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
OAuth 2.0 Token Exchange
For more information, see OAuth 2.0 Token Exchange.
- Other OAuth 2.0 Standards
JWT Proof-of-Possession
For more information, see "JWK-Based Proof-of-Possession".
Certificate-based Proof-of-Possesion
For more information, see "Certificate-Bound Proof-of-Possession".
User Managed Access (UMA) 2.0
For more information, see the ForgeRock Access Management UMA 2.0 Guide.
OpenID Connect
For more information, see the ForgeRock Access Management OpenID Connect 1.0 Guide.
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 About Authorization and Policy Decisions and Dynamic OAuth 2.0 Authorization.
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 the Internet-Draft, OAuth 2.0 Threat Model and Security Considerations, before putting your service into production.
To try the capabilities of AM as an authorization server, you can download the sample mobile application.
For information on downloading and building AM sample source code, see How do I access and build the sample code provided for AM (All versions)? in the Knowledge Base.
Related information: