Contact Us 1-800-596-4880

Configure OpenID Connect Client Management

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

The following table contains examples of the URLs you need to supply, depending on your 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

  1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.

  2. In the navigation bar or the main Anypoint Platform page, click Access Management.

  3. In the Access Management navigation menu, click Client Providers.

  4. Click Add Client Provider, and then select OpenID Connect Dynamic Client Registration.

    The Add OIDC client provider page appears.

  5. After obtaining values from your identity provider’s configuration, complete the following required fields in each section:

    • Dynamic Client Registration

      • Issuer: URL that the OpenID provider asserts is its trusted issuer.

      • Client Registration URL: The URL to dynamically register client applications as a client application for your identity provider.

      • Authorization Header: The header to provide credentials to authenticate with a server. This header is required if the provider restricts registration requests to authorized clients.

        • For Okta, this value is SSWS ${api_token}, where api_token is an API token created through Okta.

        • For ForgeRock, this value is Bearer ${api_token}, where api_token is an API token created through ForgeRock.

        • For Salesforce, this value is Bearer ${api_token}, where api_token is an API token created through Salesforce. In Advanced Settings you can also select:

        • 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.

          • 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 is 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.
            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"
            }
            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 is an example of the DELETE request header:

            DELETE /oauth2/connect/register/{{client_id}}
            Host: identity.example.com
            Authorization: Bearer access-token
            Neither the PUT nor the DELETE are expected to 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.
      • Client Request Timeout (seconds): The time elapsed before a client provider request times out. The minimum value is five seconds. The maximum value is 20 seconds.

    • 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 should be a "Confidential" client.

        • For ForgeRock, this value should be a "Confidential" client.

        • For Salesforce, this value should be a "Confidential" client.

      • Client Secret: The client secret that corresponds to the client ID.

    • OpenID Connect Authorization URLs

      • Authorize URL: The URL where the user authenticates and grants OpenID Connect client applications access to the user’s identity.

      • Token URL: The URL that provides the user’s identity, encoded in a secure JSON Web Token.

  6. Click Create.

Once 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 needs to assign the dynamically generated clients to a user or a group of users in order for them to receive access tokens by sending over the Client ID and Client Secret.
When Anypoint Platform makes an HTTP call to the configured OIDC endpoints, the HTTP call times out if no response after 5 seconds.

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 of 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 this spec on the $ISSUER/.well-known/oauth-authorization-server endpoint, the endpoint is discovered and validated prior to 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, save it again, and the grant types are updated 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 the following 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.