---
title: Dynamic OAuth 2.0 authorization
description: Advanced Identity Cloud can grant OAuth 2.0 scopes statically or dynamically:
component: pingoneaic
page_id: pingoneaic:am-authorization:oauth2-authorization
canonical_url: https://docs.pingidentity.com/pingoneaic/am-authorization/oauth2-authorization.html
keywords: ["Authorization", "OAuth 2.0", "Scope", "Policy"]
page_aliases: ["authorization-guide:oauth2-authorization.adoc"]
section_ids:
  example_use_case: Example use case
  how_it_works: How it works
  validate_oauth_2_0_scope_policies: Validate OAuth 2.0 scope policies
  prepare_a_demonstration: Prepare a demonstration
  oauth2-authz-scope-policy: OAuth 2.0 scope policy
  oauth2-authz-client: OAuth 2.0 client
  oauth2-authz-resource-owner: Resource owner
  test_the_demonstration: Test the demonstration
  non_interactive: Non-interactive
  interactive: Interactive
---

# Dynamic OAuth 2.0 authorization

Advanced Identity Cloud can grant OAuth 2.0 scopes statically or dynamically:

* Static scopes (default)

  OAuth 2.0 client configurations specify the allowed and, optionally, default scopes.

  When the client requests allowed scopes and the resource owner consents to grant the client access, Advanced Identity Cloud issues the token with the scopes requested.

  When different users use the same client that requests scopes `A` and `B`, the access token always includes scopes `A` and `B`.

* Dynamic scopes

  OAuth 2.0 client configurations specify the allowed and, optionally, default scopes.

  You configure policies for OAuth 2.0 scope decisions. You configure the client or the OAuth 2.0 provider service to use the policy engine for scope decisions.

  Advanced Identity Cloud checks each scope against the applicable OAuth 2.0 scope policies and grants or denies access to scopes dynamically.

  When different users use the same client that requests scopes `A` and `B`, the access token scopes can differ.

## Example use case

A company supports custom OAuth 2.0 clients for internal applications. The use of the internal applications is bound by the terms and conditions in the contracts of those who work for the company. The terms and conditions grant the internal applications access to profile information the company maintains. It would be redundant to prompt employees and contractors for consent to access their profile information.

An Advanced Identity Cloud administrative user creates policies to grant the `profile` scope for all internal client tokens.

## How it works

![How policies determine whether to grant or deny an OAuth 2.0 scope](_images/oauth2-realm-app-policy-overview.png)Figure 1. Policies for dynamic scopes

Advanced Identity Cloud processes consent based on the policy decision:

* If a policy grants access to a scope (`GRANT=true`), consent is automatic.

  Advanced Identity Cloud does not prompt the user to grant access.

* If a policy denies access to a scope (`GRANT=false`), Advanced Identity Cloud omits the scope from any resulting token.

  Advanced Identity Cloud does not prompt the user to grant access.

* If no policy grants or denies access, then the result depends on the flow.

  When the flow is interactive as in authorization or device code flows, Advanced Identity Cloud prompts the user to grant access or uses the saved consent state if available.

  If the flow is not interactive as in resource owner password or client credentials flows, Advanced Identity Cloud omits the scope from any resulting token.

  For details about which flows are interactive, refer to the examples in [OAuth 2.0 grant flows](../am-oauth2/oauth2-implementing-flows.html) and [OIDC grant flows](../am-oidc1/oidc-implementing-flows.html).

The default scopes behavior does not change for dynamic authorization. Advanced Identity Cloud only evaluates default scopes from the OAuth 2.0 client profile when the client does not request a scope. Advanced Identity Cloud follows the same rules to deduce consent for both default and requested scopes.

When issuing refresh tokens, Advanced Identity Cloud issues the same scopes as for the access token, unless a policy explicitly denies one of the scopes.

## Validate OAuth 2.0 scope policies

Writing policies for OAuth 2.0 may not be straightforward if your environment requires complex conditions. The easiest way to validate OAuth 2.0 policies is to configure a client to use the policies and request some tokens.

## Prepare a demonstration

Start by preparing the demonstration:

* [Create a sample policy](#oauth2-authz-scope-policy).

* [Create an OAuth 2.0 client](#oauth2-authz-client).

* [Create a resource owner account](#oauth2-authz-resource-owner).

### OAuth 2.0 scope policy

The sample scope policy denies access to the `email` scope.

1. Under Native Consoles > Access Management, go to Realms > alpha > Authorization > Policy Sets and select Default OAuth2 Scopes Policy Set to edit the policy set.

   This is the `oauth2Scopes` policy.

2. Click + Add a Policy, use the following settings, and create the policy:

   * Name

     `Dynamic OAuth 2.0 Scopes`

   * Resource Type

     `OAuth2 Scope`

   * Resources

     Select `*` as the pattern and add `email` as the scope.

3. Click the Actions tab, set `GRANT` to `Deny`, and save your changes.

4. Click the Subjects tab, set the subject type to `Authenticated Users`, and save your changes.

The resulting policy reflects your work:

![OAuth 2.0 policy denying the email scope for all authenticated users](_images/oauth2-scope-policy.png)Figure 2. OAuth 2.0 scopes policy

### OAuth 2.0 client

The OAuth 2.0 client profile in this example overrides the OAuth 2.0 provider settings. This lets you test the scope policy without affecting other clients.

1. Create a confidential OAuth 2.0 client account.

   In the Advanced Identity Cloud admin console, select Applications > + Add Application, and create a new Web client with the following settings:

   * Client ID

     `myClient`

   * Client Secret

     `mySecret`

2. Add the following settings in the client profile and save your work:

   * Name

     `Dynamic scopes client`

   * Sign-in URLs

     `https://www.example.com:443/callback`

   * Grant Types

     `Authorization Code`\
     `Client Credentials`\
     `Implicit`\
     `Refresh Token`\
     `Resource Owner Password Credentials`

   * Scopes

     `openid`\
     `profile`\
     `email`

3. Override the OAuth 2.0 Provider settings for this client.

   Under Native Consoles > Access Management, select Realms > alpha > Applications > OAuth 2.0 > Clients > myClient. Switch to the OAuth2 Provider Overrides tab, update the following settings, and save your work:

   * Enable OAuth2 Provider Overrides

     Enabled

   * Use Policy Engine for Scope decisions

     Enabled

   * Scopes Policy Set

     `oauth2Scopes`

### Resource owner

Create the OAuth 2.0 resource owner account:

1. In the Advanced Identity Cloud admin console, select Identities > Manage > Alpha Realm - Users > + New Alpha Realm - User and fill the required fields.

2. Record the username and password.

## Test the demonstration

Test the feature with non-interactive and interactive flows.

### Non-interactive

This test uses the [resource owner password credentials](../am-oauth2/oauth2-ropc-grant.html) flow:

* The OAuth 2.0 client credentials are `myClient:mySecret`.

* The resource owner credentials are the username and password you recorded; here, `test:Secret12!`.

* The requested scopes are `openid` and `email`.

```bash
$ curl \
--request POST \
--user 'myClient:forgerock' \
--data 'scope=openid email' \
--data 'grant_type=password' \
--data 'username=test' \
--data 'password=Secret12!' \
'https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/access_token'
{
  "access_token": "...",
  "refresh_token": "...",
  "scope": "openid",
  "id_token": "...",
  "token_type": "Bearer",
  "expires_in": 3599
}
```

Notice the access token has `"scope": "openid"`. Advanced Identity Cloud removed `email` from the scopes.

### Interactive

This test uses the [implicit](../am-oauth2/oauth2-implicit-grant.html) flow. It stops after demonstrating the user consent phase of the process.

1. Update the client configuration to require resource owner consent.

   In the Advanced Identity Cloud admin console, go to Applications > myClient > Sign On > General Settings, click Show advanced settings.

   Under Authentication, clear Implied Consent and save your change.

2. In a web browser, go to the `/authorize` endpoint to initiate the implicit flow.

   ```none
   https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/authorize?scope=openid+profile+email&response_type=id_token&client_id=myClient&nonce=123&state=456&redirect_uri=https://www.example.com:443/callback
   ```

3. Sign in with the resource owner's credentials.

4. Observe the prompt for consent that does not include the `email` scope:

   ![Advanced Identity Cloud prompts for consent to access the profile scope.](_images/oauth2-example-oidc.png)Figure 3. Consent for the profile scope