--- schema_version: "1" id: 5182127dd3fb75bb67ca1e4179fd844ff92c0fd8cf54c407081f7e896084d8c5 title: Configuring OpenID Connect Client Management in Anypoint Platform collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/access-management/configure-client-management-openid-task.md canonical_url: https://docs.mulesoft.com/access-management/configure-client-management-openid-task source_site: docs.mulesoft.com content_type: documentation content_hash: c14cca8507b53c25c20ba05388aecf1c0ba256849ed56fc52250249b49e5ecd5 description: MuleSoft Documentation Site latest: true --- --- product: Access Management version: master --- # Configuring OpenID Connect Client Management in Anypoint Platform > For the full documentation index, see: https://docs.mulesoft.com/llms.txt 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. API portals dynamically register client applications with your chosen external IdP when requesting access. 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 1. Sign in to Anypoint Platform using an account that has the Organization Administrator permission. 2. Select **Access Management** from the ![gear icon](/mulesoft/current/en-us/access-management/_images/gear.svg) menu. 3. In the Access Management navigation menu, click **Client Providers**. 4. Click **Add Client Provider**, and then select **OpenID Connect Dynamic Client Registration**. 5. Enter the values from your IdP’s configuration 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

{BASE URL}/authorize

{BASE URL}/authorize

Token

{BASE URL}/token

{BASE URL}/access_token

{BASE URL}/token

Token Introspection

{BASE URL}/introspect

{BASE URL}/introspect

{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. > [!NOTE] 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`. 6. 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.

1. 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. 7. 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. 8. 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. 9. 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. > [!NOTE] 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**. > [!NOTE] `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 > [!IMPORTANT] 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 the [Access Management API](https://dev-portal.mulesoft.com/apis/access-management.html) 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](https://datatracker.ietf.org/doc/html/rfc8414#section-3) 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](https://docs.mulesoft.com/exchange/): - Implicit - Authorization - Refresh Token > [!NOTE] You can select the Refresh Token grant type only if you have also selected the > Authorization grant type. ## See Also - [About OpenAM, OpenID Connect, or PingFederate OAuth Token Enforcement Policies](https://docs.mulesoft.com/mule-gateway/policies-included-openam-oauth-token-enforcement) - [About OAuth 2.0](https://docs.mulesoft.com/api-manager/latest/mule-oauth-provider-landing-page) - [How to find your Microsoft Entra ID tenant ID](https://learn.microsoft.com/en-us/entra/fundamentals/how-to-find-tenant). - [OpenAM 13.5 Developer’s Guide, Procedure 14.4 To Register a Relying Party Dynamically](https://docs.pingidentity.com/archive/) - [Okta OpenID Connect, Dynamic Client Registration](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/client) - [OpenAM 13.5 Administration Guide, Procedure 14.5 To Register a Relying Party Dynamically](https://cdn-docs.pingidentity.com/archive/pdf/openam/13.5/OpenAM-13.5-Admin-Guide.pdf) - [Okta OpenID Connect, Dynamic Client Registration](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/Client/) - [Okta OpenID Connect & OAuth 2.0 API](https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/) - [AM 5 OAuth 2.0 Guide, 3.1. OAuth 2.0 Client and Resource Server Endpoints](https://cdn-docs.pingidentity.com/archive/pdf/am/5/AM-5-Oauth2-Guide.pdf?_gl=1*1vvi2cj*_gcl_au*MjAxNDYzMjg5Ni4xNzc2MzcxMDA3*_ga*MTYwNDgyOTczOC4xNzc2MzcwOTk5*_ga_V94KKVLZPT*czE3NzYzNzA5OTkkbzEkZzEkdDE3NzYzNzE0MDAkajYwJGwwJGg4OTk1NTUwMDI) - [How to reset secrets for client applications when using external client management](https://help.salesforce.com/s/articleView?id=001115835&type=1)