--- title: Configure Advanced Identity Cloud as an authorization server description: Configure Advanced Identity Cloud as an OAuth 2.0 authorization server for client and admin endpoints component: pingoneaic page_id: pingoneaic:authorization:oauth2-provider canonical_url: https://docs.pingidentity.com/pingoneaic/authorization/oauth2-provider.html llms_txt: https://docs.pingidentity.com/pingoneaic/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md keywords: ["OAuth 2.0", "Endpoints", "Authorization", "Setup & Configuration"] page_aliases: ["oauth2-guide:oauth2-configure-authz.adoc am-oauth2:oauth2-configure-authz.adoc"] section_ids: core-behavior-and-lifetimes: Core behavior and lifetimes grant-types: Grant types token-and-code-lifetimes: Token and code lifetimes persistence: Persistence scopes-and-consent-model: Scopes and consent model consent-behavior: Consent behavior token-storage: Token storage (client-side or server-side) oidc-specific-settings: OIDC-specific settings subject-type-and-hash-salt: Subject type and hash salt claims-mapping-and-scripts: Claims mapping and scripts dynamic-client-registration: Dynamic client registration (DCR) scripted-jwt-issuers: Scripted JWT issuers --- # Configure Advanced Identity Cloud as an authorization server The OAuth2 Provider configures Advanced Identity Cloud as an OAuth 2.0 authorization server for a realm. It exposes the [OAuth 2.0 endpoints](../am-oauth2/oauth2-client-endpoints.html) and [OAuth 2.0 administration endpoints](../am-oauth2/oauth2-admin-endpoints.html), providing a centralized, standards-compliant location to handle access tokens and authorization decisions for your applications and APIs. Learn more about [how Advanced Identity Cloud works as an authorization server](../am-oauth2/am-as-authz-server.html). The OAuth2 Provider is highly configurable, but if you're just getting started with your Advanced Identity Cloud tenant, most defaults are safe to use as-is. It follows a simple inheritance model: * **Realm-wide defaults**: Client applications inherit baseline settings directly from the provider. * **Shared overrides**: You can use client groups to share custom settings across multiple clients. * **Client-specific overrides**: You can override settings on individual clients when specific parameters (such as token lifetimes, scripts, token storage, or consent behavior) must diverge from the provider default. To configure the OAuth2 Provider: 1. In the Advanced Identity Cloud admin console, go to [icon: vpn_key, set=material, size=inline] Authorization > OAuth2 Provider. 2. Update the OAuth 2.0 settings as needed. 3. Click [icon: add, set=material, size=inline] Save. Find a comprehensive list of configuration options in [OAuth 2.0 provider](../am-reference/services-configuration.html#realm-oauth-oidc). Consider the following key areas when configuring your settings. ## Core behavior and lifetimes ### Grant types Go to [icon: vpn_key, set=material, size=inline] Authorization > OAuth2 Provider > Advanced to find these settings. Select the Grant Types that client applications can use to request access, refresh, and ID tokens. Select only the grant types you plan to use, for example, Authorization Code, Refresh Token, Client Credentials, Token Exchange, and Device Code. Find a list of supported grant types in [OAuth 2.0 grant flows](../am-oauth2/oauth2-implementing-flows.html) and [OpenID Connect grant flows](../am-oidc1/oidc-implementing-flows.html). | | | | - | ------------------------------------------------------------------------------ | | | UMA is listed but isn't supported in Advanced Identity Cloud. Don't select it. | ### Token and code lifetimes Go to [icon: vpn_key, set=material, size=inline] Authorization > OAuth2 Provider > Core to find these settings. * Authorization Code Lifetime (seconds) Keep the authorization code lifetime short (less than 10 minutes per [RFC 6749](https://www.rfc-editor.org/info/rfc6749/)). The default value is 2 minutes. * Refresh Token Lifetime and Access Token Lifetime Set access and refresh token lifetimes to match your risk posture. The defaults are usually fine to start with, but assess these values with your security team. * Issue Refresh Tokens If you plan to use refresh tokens, configure the provider to issue them and make sure your selected grant types support them. Learn why refresh tokens are useful in your environment, and how to request them in [Refresh tokens](../am-oauth2/oauth2-refresh-tokens.html). ### Persistence Go to [icon: vpn_key, set=material, size=inline] Authorization > OAuth2 Provider > Advanced to find these settings. *Persistence* lets you retain custom claims when you refresh an access token. In the Persistent Claims field, enter the claims that must be persisted between tokens. When an access token is refreshed, any claims that are listed here will be on the new token. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | * These claims are added before the access token modification script, allowing you to manipulate them in the modification script. For example, if a token has a claim called `hostname` that you want to be persisted when the token is refreshed, you could add that claim to the Persistent Claims list. You could then modify the script to persist that `hostname` in the new token, if it exists, or to add a hostname to the new token, if it doesn't exist. * Only custom, non-standard claims can be persisted. Standard claims, such as `scope` (defined in the OAuth 2.0 specification) and `auditTrackingId` (defined by default in Advanced Identity Cloud) can't be persisted. | ## Scopes and consent model Go to [icon: vpn_key, set=material, size=inline] Authorization > OAuth2 Provider > Advanced to find these settings. * Client Registration Scope Allowlist If you plan to use [Dynamic client registration (DCR)](#dynamic-client-registration), enter the set of scopes allowed when clients register dynamically. This list also controls which scopes can appear in consent and discovery metadata. * Default Client Scopes Decide which scopes should be default at the provider level. If a client application doesn't request any scope, the provider defaults apply. If no provider defaults are set, the client defaults are used. ### Consent behavior Go to [icon: vpn_key, set=material, size=inline] Authorization > OAuth2 Provider > Consent to find these settings. The settings control whether: * Your end users are asked for [consent](../am-oauth2/oauth2-manage-consent.html). * Your end users can save consent so the OAuth 2.0 provider remembers their consented scopes. * Client applications can skip consent so no consent page is displayed to resource owners. * Client applications can revoke consent. * Consent is handed off to a [Remote Consent Service](remote-consent-service.html). ## Token storage (client-side or server-side) By default, Advanced Identity Cloud stores OAuth 2.0 tokens client-side. If you need server-side (CTS) storage (for operational, revocation, or audit reasons), go to [icon: vpn_key, set=material, size=inline] Authorization > OAuth2 Provider > Core and deselect Use Client-Side Access & Refresh Tokens. If you don't have a strong requirement, leave the default client-side setting. | | | | - | ----------------------------------------------------- | | | You can override this setting per client application. | ## OIDC-specific settings You configure Advanced Identity Cloud as an OpenID Provider (OP) when you want it to be the central identity service that authenticates users and tells applications *who* the user is, not just whether they can get an access token. If you're using Advanced Identity Cloud as an OpenID Provider: ### Subject type and hash salt Go to [icon: vpn_key, set=material, size=inline] Authorization > OAuth2 Provider > Advanced to find these settings. * Subject Types supported Ensure this setting includes `pairwise` (default). When a client application is configured to use `pairwise`, the OP (Advanced Identity Cloud) returns a different, opaque subject value per client instead of a single global value. This prevents different clients from easily correlating the same end user across applications, improving privacy. For a client application to use `pairwise`, its subject type must be included in this list. Otherwise, you'll see the error `Server does not support this client's subject type.` * Subject Identifier Hash Salt By default, this field is set to `&{am.oidc.client.subject.identifier.hash.salt}`. If you're supporting `pairwise` subject types, you must change this value from the default to a tenant-specific value for privacy-preserving pairwise subject IDs. Because the hash salt is part of how pairwise `sub` values are computed, leaving it at the default effectively breaks the privacy guarantees of pairwise subjects. ### Claims mapping and scripts Go to [icon: vpn_key, set=material, size=inline] Authorization > OAuth2 Provider > Advanced OpenID Connect to find these settings. * Always Return Claims in ID Tokens This option is enabled by default and enables scope-derived claims in ID tokens. This is useful if your relying parties need user profile data immediately at sign-in, without extra calls to `/userinfo`. If you keep this option enabled, you must also configure how Advanced Identity Cloud maps scopes to claims and user profile attributes. Find more information in [Claims](../am-oidc1/understanding-openid-connect-scopes-and-claims.html) and [OIDC claims](../am-oauth2/plugins-user-info-claims.html). ## Dynamic client registration (DCR) If you plan to onboard clients dynamically, configure the settings on the Client Dynamic Registration tab. Decide on the following: * If your client applications can register without an access token, set Allow Open Dynamic Client Registration. Allowing open dynamic client registration is a trade-off between ease of onboarding and control. The advantages are zero-bootstrap onboarding and a more open self-service ecosystem. The disadvantages are security exposure of the registration endpoint, need for extra protections, and weaker governance and auditability. In most production Advanced Identity Cloud deployments you keep open registration disabled and use access-token-protected DCR, reserving open registration for tightly controlled test or demo environments with strong rate limiting and monitoring. * If you require a software statement JWT, set Require Software Statement for Dynamic Client Registration. * Enable this option if third-party or high-risk clients register or if you need strong provenance and policy-controlled metadata (for example, open banking and FAPI-style ecosystems). * Leave this option disabled for internal or low-risk environments where you already trust registrants and want simpler, faster self-service DCR without managing software statements. * If you enable this option, also set the Required Software Statement Attested Attributes to the list of claims that must be present in the software statement JWT. Learn more in [Dynamic client registration](../am-oidc1/oauth2-dynamic-client-registration.html) (DCR). ## Scripted JWT issuers Scripted JWT issuers let a script represent a trusted JWT issuer, so Advanced Identity Cloud can dynamically retrieve the issuer's details during the JWT profile for authorization grant. Learn more in [Configure a scripted JWT issuer^](../am-oauth2/oauth2-jwt-bearer-grant.html#configure-scripted-jwt-issuer).