Configuring OpenID Connect Client Management

Configure an external OpenID Connect (OIDC) identity provider (IdP) to handle client management for your Anypoint Platform APIs. Use providers supporting the OIDC Dynamic Client Registration (DCR) standard, such as Salesforce, Okta, or OpenAM. This allows API portals to dynamically register client applications with your chosen external IdP when requesting access.

Anypoint Platform supports client management by identity providers that implement the OpenID Connect Dynamic Client Registration open standard. Salesforce, Okta, and OpenAM v14 Dynamic Client Registration are explicitly supported in Anypoint Platform.

Anypoint Platform supports client authentication using an Authorization Header or by using the private key JSON Web Token (JWT) method. With the private key method, during dynamic client registration, Anypoint Platform signs a JWT with a user-provided private key and sends it to the IdP as a client assertion. The IdP validates the signature using a pre-registered public key and, if successful, issues a short-lived access token used solely to register a new client. This approach enhances security by allowing you to control the token lifespan and restrict scopes to only those that are necessary.

Configure Client Management

Sign in to Anypoint Platform using an account that has the root Organization Administrator permission.
In the navigation bar or the main Anypoint Platform page, click Access Management.
In the Access Management navigation menu, click Client Providers.
Click Add Client Provider, and then select OpenID Connect Dynamic Client Registration.

After you have the values from your IdP’s configuration, complete the information for your client provider, enter the information for Dynamic Client Registration:

Issuer

URL that the OpenID provider asserts is its trusted issuer.

Client Registration URL

URL to dynamically register client applications as a client application for your IdP.

These are examples of client registration URLs, which are determined by your client provider, during registration:

URL Name

Okta Example URL

OpenAM Example URL

Salesforce Example URL

Base

https://example.okta.com/oauth2/v1

https://example.com/openam/oauth2

https://example.salesforce.com/services/oauth2

Client Registration

{BASE URL}/clients

{BASE URL}/connect/register

{BASE URL}/register

Authorize

{BASE URL}/authorize

Token

{BASE URL}/token

{BASE URL}/access_token

{BASE URL}/token

Token Introspection

{BASE URL}/introspect

Client Request Timeout (seconds)

The time that elapses before a client provider request times out. The minimum value is five seconds. The maximum value is 20 seconds.

Anypoint Platform makes an HTTP call to the configured OIDC endpoints, and if there is no response after five seconds, the HTTP call times out.
1. Select Advanced Settings for these options:
Disable server certificate validation

Disables server certificate validation if your OpenID client management instance presents a self-signed certificate, or one signed by an internal certificate authority.
Enable client deletion in Anypoint Platform

Enables deletion of clients created with this integration.
Enable client deletion and updates in IdP

To use this option, you must also select the Enable client deletion in Anypoint Platform option. This option enables you to update and delete external clients in the configured IdP through an outbound call made by Anypoint Platform to {clientRegistrationUrl}/{clientID}. The clientRegistrationUrl is the value you configured in Client Registration URL. For example: https://identity.example.com/oauth2/connect/register/6779ef20e75817b79602.

In Authentication Method, complete the information for the type of authentication to use for this client provider:

Authorization Header

The HTTP authorization header provides a static token that doesn’t expire to authenticate with a server. This header is required if the provider restricts registration requests to authorized clients. If you prefer to use short-lived bearer access tokens, use the OAuth 2.0 private key option instead.

Client Provider

Value

Okta

SSWS ${api_token}, where api_token is an API token created through Okta.

ForgeRock

Bearer ${api_token}, where api_token is an API token created through ForgeRock.

Salesforce

Bearer ${api_token}, where api_token is an API token created through Salesforce.

Select Use OAuth2 private key jwt to use a private key instead of an authorization header, and provide these values:

Token Client ID

This is the unique identifier of the application (client ID) registered within your IdP. It’s used to identify the calling application when requesting a bearer token from Anypoint Platform during client registration.
Token Client Private Key

This is the cryptographic key in PEM format used by Anypoint Platform to sign the JWT for authenticating with the IdP. The corresponding public key must be stored in the IdP in advance. When the IdP reads the signed JWT and validates the signature, the IdP issues an access token used for Anypoint Platform to register a new client in the IdP.
Token Client API Scopes

The client API scopes define the specific permissions granted to the token client with the scopes to register new clients.

Enter the information for the Token Introspection Client:
- Client ID: The client ID for an existing client in your IdP capable of introspection of all tokens from all clients.
  - For Okta, this value is a "Confidential" client.
  - For ForgeRock, this value is a "Confidential" client.
  - For Salesforce, this value is a "Confidential" client.
- Client Secret: The client secret that corresponds to the client ID.
Enter the information for OpenID Connect Authorization URLs:
- Authorize URL
  
  URL where the user authenticates and grants OpenID Connect client applications access to the user’s identity.
- Token URL
  
  URL that provides the user’s identity, encoded in a secure JSON Web Token.
Click Create.

After this is successfully configured, you can apply the OpenID Connect OAuth Token Enforcement policy to your API Gateways through API Manager. Requesting API access through API portals dynamically generates client applications in the configured IDP that acts as a token provider.

For Okta, the Okta admin must assign the dynamically generated clients to a user or a group of users so they can receive access tokens by sending over the Client ID and Client Secret.

Client Application Updates and Deletes

OKTA or another IdP might allow client modification and deletion independently, but this isn’t supported on Anypoint Platform. Instead, Anypoint Platform provides and supports hooks so you can implement API calls that are particular to your IdP.

These examples show PUT and DELETE requests that Anypoint Platform makes.

This is an example of the payload for a PUT (update) request:

PUT /oauth2/connect/register/{{client_id}}
Accept: application/json
Host: identity.example.com
Authorization: Bearer access-token
 {
     "client_id": "client_id",
     "client_secret": "some-secret",
     "redirect_uris": [
          "https://example.com/"
      ],
     "grant_types": [ "authorization_code" ],
     "token_endpoint_auth_method": "client_secret_basic",
     "response_types": [ "code" ],
     "client_name": "test-client-name"
}

The Authorization: header is included as part of the request only if the Authorization Header under Advanced settings is configured.
The client_id request parameter that’s passed is the same as the client_id passed in the PUT request payload.
The token_endpoint_auth_method passed in the payload is always client_secret_basic.

Only the Client Registration URL and Authorization Header come from what is configured in OIDC Client Provider.

client_name in the request maps to name on the inbound side.
The authorization method depends on the grant type. For example, if the grant type is implicit, the id_token and token are returned.

This example shows another DELETE request header:

DELETE /oauth2/connect/register/{{client_id}}
Host: identity.example.com
Authorization: Bearer access-token

Neither the PUT nor the DELETE work if the call is used directly against an IdP. It’s intended for interception by pointing to an application under your control, so you can implement the correct deletion and update APIs for their particular provider.

Update External Clients Via the API

You can use the Access Management API call PUT /accounts/api/organizations/{orgId}/clientProviders/{clientProviderId}/clients/{clientId} to update external clients. Use the optional force parameter to update Anypoint Platform internal client application records, regardless of whether the update to the external IdP is successful. Using this parameter ensures that the view Anypoint Platform has of the client application is current, even if there are issues communicating with the IdP.

If you don’t use the force parameter, when updating an external client application via the Anypoint Platform API, Anypoint Platform first attempts to update the Identity Provider (IdP) and then updates its internal records only if the IdP update is successful.

For more information, see Access Management API documentation.

Supported Grant Types

Pre-populated Grant Types in API Portal

If you configure the optional Issuer field while setting up the OIDC Dynamic Client registration provider, Anypoint Platform autopopulates its UI with all the OIDC grant types supported by the provider, such as client credentials, password, and more.

To verify the grant types your provider supports, check the provider’s discovery endpoint using $ISSUER/.well-known/openid-configuration, where $ISSUER is the issuer configured as the provider.

If the client provider supports RFC 8414, Obtaining Server Metadata on the $ISSUER/.well-known/oauth-authorization-server endpoint, the endpoint is discovered and validated before merging grant types with $ISSUER/.well-known/openid-configuration. This process also enables the use of the Client Credentials grant type for Okta users.

Update Grant Types

If the Issuer is set and the /.well-known URL is available, you can go to an existing client provider, and save it again to update the grant types based on the grant_types_supported from your /.well-known metadata. The system fetches the /.well-known metadata when you create or update a client provider.

Default Grant Types

If the Issuer field isn’t configured or the provider’s discovery endpoint is unavailable, by default the Anypoint Platform UI lists these grant types when registering an API client application in an Anypoint Exchange API portal:

Implicit
Authorization
Refresh Token

You can select the Refresh Token grant type only if you have also selected the Authorization grant type.