PingOne Advanced Identity Cloud

Configure a DCR onboarding flow

To streamline the onboarding of OAuth 2.0 clients, Advanced Identity Cloud supports Dynamic Client Registration (DCR), which allows for the automated creation and configuration of dynamic clients without manual intervention.

In addition to the standard DCR endpoint (/register), Advanced Identity Cloud provides an AI agent-specific DCR endpoint (/aiagent/register) for onboarding AI agents as dynamic clients, enabling your AI-driven solutions to programmatically register and obtain credentials for secure access to applications on behalf of end users.

What is Dynamic Client Registration (DCR)?

Dynamic Client Registration (DCR) is an OAuth 2.0 extension that allows dynamic clients to be programmatically registered with an authorization server at runtime without manual administrative intervention. Instead of a static setup, dynamic clients send their own metadata (including names and authorized redirect URLs) directly to a dedicated registration endpoint to obtain unique credentials. This process is essential for scaling high-velocity environments where numerous individual client instances require distinct identities for secure tracking and lifecycle management.

DCR is a key component of Model Context Protocol (MCP) authorization, where MCP clients such as AI assistants and IDEs need to interact securely with MCP servers that host data and tools. DCR allows these MCP clients to be dynamically onboarded with appropriate access permissions and security settings, enabling seamless and secure interactions in AI-driven solutions.

Task 1: Configure the OAuth 2.0 provider service

Configure the OAuth 2.0 provider service to support the grant types needed for the DCR onboarding flow:

  1. In the Advanced Identity Cloud admin console, go to Native Consoles > Access Management > Services.

  2. Click the OAuth2 Provider service, then click the Advanced tab:

    1. In the Grant Types field, select the Client Credentials grant type, if it isn’t already selected.

    2. In the Client Registration Scope Allowlist field, select the scopes that AI-driven solutions can request when they use the DCR onboarding flow to onboard AI agents.

  3. Click the Client Dynamic Registration tab:

    • Select the Allow Open Dynamic Client Registration checkbox, if it isn’t already selected.

  4. Click Save Changes.

Task 2: Create and register a DCR script

Create a DCR script to configure the settings for AI agents onboarded as dynamic clients.

  1. In the Advanced Identity Cloud admin console, go to Native Consoles > Access Management > Scripts.

  2. Click add New Script.

  3. In the New Script page:

    1. Enter a Name for the script, such as AI Agent Dynamic Client Registration Script.

    2. In the Script Type drop-down list, select OAuth2 Dynamic Client Registration.

    3. Click Create.

  4. In the script editor:

    1. (Optional) Enter a Description for the script, such as Script to configure AI agent access settings during dynamic client registration.

    2. In the Script field, enter the following script:

      if (operation === "CREATE" && clientIdentity.isAIAgent()) {
        clientIdentity.setAttribute("providerOverridesEnabled", ["true"]); (1)
        clientIdentity.setAttribute("statelessTokensEnabled", ["true"]); (2)
        clientIdentity.setAttribute("acceptAudienceParametersInTokenExchangeRequests", ["true"]); (3)
      
        clientIdentity.setAttribute("AgentType", clientIdentity.getAttributeValues("AgentType")); (4)
        clientIdentity.setAttribute("aiAgentIdentityUid", clientIdentity.getAttributeValues("aiAgentIdentityUid")); (4)
      
        clientIdentity.store(); (5)
      }
      1 providerOverridesEnabled is required to enable client-specific customization for the dynamic client’s OAuth 2.0 settings.
      2 statelessTokensEnabled is required to enable stateless token issuance for the dynamic client. This allows the AI-agent dynamic client to receive self-contained tokens that don’t require Advanced Identity Cloud to look up token metadata in the database for each validation, which is ideal for high-scale AI-driven solutions.
      3 acceptAudienceParametersInTokenExchangeRequests is required to allow the AI-agent dynamic client to specify audience values in token exchange requests, which is important for ensuring that the access tokens it obtains are properly scoped for the intended target applications.
      4 The script also copies the AgentType and aiAgentIdentityUid attributes back to the client. This is a required step for dynamic clients created via the /aiagent/register endpoint.
      5 clientIdentity.store() saves the changes made to the client’s attributes.
    3. Click Save Changes.

  5. Go to Native Consoles > Access Management > Services > OAuth2 Provider.

  6. Click the Client Dynamic Registration tab, then in the Dynamic Client Registration Script drop-down list, select the DCR script you just created.

  7. Click Save Changes.

Task 3: Register and configure a dynamic client

  1. Use the AI agent-specific DCR endpoint (/aiagent/register) to register a dynamic client.

    The /aiagent/register endpoint doesn’t support setting the client ID in the request payload. The client_id is automatically generated by Advanced Identity Cloud for AI agents registered as dynamic clients.
    $ curl \
    --request POST 'https://<tenant-env-fqdn>:443/am/oauth2/realms/root/realms/<realm>/aiagent/register' \(1)(2)
    --header 'Content-Type: application/json' \
    --data '{(3)
        "grant_types": ["client_credentials"],
        "response_types": ["token"],
        "redirect_uris": <dynamic-client-redirect-uris>,(4)
        "scopes": <dynamic-client-scopes>,(5)
        "client_name": <dynamic-client-name>,(6)
        "token_endpoint_auth_method": "client_secret_post"(7)
    }'
    Show request guidance
    1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
    2 Replace <realm> with either alpha or bravo.
    3 The JSON payload contains the metadata needed to onboard a dynamic client.
    4 Replace <dynamic-client-redirect-uris> with a JSON array of one or more absolute URLs for the dynamic client you want to onboard. For example, ["https://example.com/callback"]. The URLs you set in redirect_uris act as a secure allowlist, identifying the only authorized endpoints where the authorization server can send sensitive response data, such as authorization codes or tokens, upon successful end user interaction.
    5 Replace <dynamic-client-scopes> with a JSON array of one or more scopes that the dynamic client can request. For example, ["data-read", "data-write"].
    6 Replace <dynamic-client-name> with a human-readable name for the dynamic client you want to onboard. For example, Retail Chatbot or Workforce Assistant. This name is used to identify the dynamic client to end users on consent screens and to tenant administrators within the Advanced Identity Cloud admin console.
    7 The token_endpoint_auth_method parameter defines how the dynamic client authenticates when requesting an access token. By setting this to client_secret_post, the client identifies as a confidential client that will provide its client_id and client_secret directly within the HTTP POST request body.
    {
        ...
        "providerOverridesEnabled": true,
        ...
        "client_id": "ab9da93d-e9ad-40ca-ba43-3be6eb63af3c", (1)
        ...
        "client_secret": "zhYjm03cS9…​ayPVIwZsgQ", (1)
        ...
        "grant_types": [
            "client_credentials"
        ],
        ...
        "redirect_uris": [
            "https://example.com/callback"
        ],
        ...
        "scopes": [
            "data-read",
            "data-write"
        ],
        ...
        "response_types": [
            "token"
        ]
    }
    Show response guidance
    1 Note the client_id and client_secret values. These are the credentials for the dynamic client you just onboarded. You’ll use these credentials in the next task to authenticate the dynamic client and obtain access tokens for it to access applications on behalf of end users.
  2. (Optional) Configure an application policy for the dynamic client. Learn more in Create AI agent application policies.

Task 4: Get a dynamic client access token

  1. Get an access token for the dynamic client using the Client Credentials grant type:

    $ curl \
    --request POST 'https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/access_token' \(1)
    --header 'Content-Type: application/x-www-form-urlencoded' \
    --data-urlencode 'grant_type=client_credentials' \(2)
    --data-urlencode 'client_id=<dynamic-client-client-id>' \(3)
    --data-urlencode 'client_secret=<dynamic-client-client-secret>' \(4)
    --data-urlencode 'scope=<dynamic-client-scopes>'(5)
    Show request guidance
    1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
    2 The grant_type for this request is client_credentials, which represents the Client Credentials grant type.
    3 Replace <dynamic-client-client-id> with the client ID of the dynamic client you registered in task 3. For example, ab9da93d-e9ad-40ca-ba43-3be6eb63af3c.
    4 Replace <dynamic-client-client-secret> with the client secret of the dynamic client.
    5 Replace <dynamic-client-scopes> with some or all of the scopes you assigned to the dynamic client. For example, data-read.
    {
        "access_token": "eyJ0eXAiOi...l2Yz6xCHHu0", (1)
        "scope": "data-read",
        "token_type": "Bearer",
        "expires_in": 3599
    }
    Show response guidance
    1 The access_token value in the response is the dynamic client’s access token.
  2. Introspect the dynamic client’s access token to verify the claims contain expected values:

    $ curl -G \
    --request GET 'https://<tenant-env-fqdn>/am/oauth2/realms/root/realms/alpha/tokeninfo' \(1)
    --data-urlencode 'access_token=<dynamic-client-access-token>'(2)
    Show request guidance
    1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
    2 Replace <dynamic-client-access-token> with the dynamic client’s access token from the response in step 2.
    {
        "sub": "ab9da93d-e9ad-40ca-ba43-3be6eb63af3ca", (1)
        "cts": "OAUTH2_STATELESS_GRANT",
        "auditTrackingId": "a910ad63-6b82-48d9-935c-52e962266243-289468",
        "subname": "ab9da93d-e9ad-40ca-ba43-3be6eb63af3c",
        "iss": "https://<tenant-env-fqdn>:443/am/oauth2/realms/root/realms/alpha",
        "tokenName": "access_token",
        "token_type": "Bearer",
        "data-read": "",
        "authGrantId": "Br5_jYrhYK...iohBrU2hs4",
        "client_id": "ab9da93d-e9ad-40ca-ba43-3be6eb63af3c",
        "access_token": "eyJ0eXAiOi...4Pmh8fD2c4",
        "aud": "ab9da93d-e9ad-40ca-ba43-3be6eb63af3c", (2)
        "nbf": 1778768831,
        "grant_type": "client_credentials",
        "scope": [
            "data-read" (3)
        ],
        :...
    }
    Show response guidance
    1 The sub claim represents the subject of the token, which in this case is the dynamic client itself, identified by its client ID.
    2 The aud claim represents the audience of the token, which in this case is the client ID of the dynamic client, indicating that the token is intended for use by that client.
    3 The scope claim contains the scopes that the dynamic client can access.