From 1dfeb216ae26935ea6477344b4280811e98f7ec8 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Mon, 9 Mar 2026 16:47:10 -0700 Subject: [PATCH 1/8] W-21449660 new feature to manage dynamic client registration --- ...nfigure-client-management-openid-task.adoc | 62 ++++++++++++------- 1 file changed, 39 insertions(+), 23 deletions(-) diff --git a/modules/ROOT/pages/configure-client-management-openid-task.adoc b/modules/ROOT/pages/configure-client-management-openid-task.adoc index 22e46cbc..beaab0ec 100644 --- a/modules/ROOT/pages/configure-client-management-openid-task.adoc +++ b/modules/ROOT/pages/configure-client-management-openid-task.adoc @@ -1,8 +1,6 @@ = 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. +Configure an external OpenID Connect (OIDC) identity provider (IdP) to handle client management for your Anypoint Platform APIs. Anypoint Platform supports IdPs that implement the OpenID Connect Dynamic Client Registration (DCR) standard; Salesforce, Okta, and OpenAM (v14 for OpenAM) are explicitly supported. This allows API portals to 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. @@ -49,7 +47,10 @@ Disables server certificate validation if your OpenID client management instance 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+`. +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+`. +* *Use registration credentials for client management* ++ +For IdPs that support the RFC 7592 web standard (such as ForgeRock), check this box to enable direct updates and deletions of dynamically registered client applications through Anypoint Platform. See <> for steps to enable this after your client provider is configured. . In *Authentication Method*, complete the information for the type of authentication to use for this client provider: * *Authorization Header* + @@ -73,10 +74,7 @@ This is the cryptographic key in PEM format used by Anypoint Platform to sign th + 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 ID*: The client ID for an existing client in your IdP capable of introspection of _all_ tokens from all clients. For Okta, ForgeRock, and Salesforce, this must be a Confidential client. * *Client Secret*: The client secret that corresponds to the client ID. . Enter the information for *OpenID Connect Authorization URLs*: * *Authorize URL* @@ -87,16 +85,36 @@ URL where the user authenticates and grants OpenID Connect client applications a 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. +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 +[[manage-dynamic-client-registration-and-lifecycle-updates]] +== Manage Dynamic Client Registration and Lifecycle Updates + +Anypoint Platform supports lifecycle management (create, update, and delete) of dynamically registered OAuth2 clients for any IdP that supports the RFC 7592 web standard (such as ForgeRock). For these IdPs, Platform supports and persists the per-client registration token (for example, `registration_access_token` and `registration_client_uri`) returned by the IdP for each newly created client, so you can update and delete those clients directly through Anypoint Platform. This capability is optional; you can use it or keep existing behavior (for example, hooks). Backward compatibility is maintained. + +For IdPs that do not support RFC 7592, Anypoint Platform provides hooks so you can implement API calls that are particular to your IdP. -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. +[[enable-direct-client-management]] +=== Enable Direct Client Management -These examples show PUT and DELETE requests that Anypoint Platform makes. +To enable direct client updates and deletions for RFC 7592-compliant IdPs: + +. Navigate to *Access Management* and click *Client Providers*. +. Select your configured client provider. +. Under the *Advanced settings* section, check the box for *Use registration credentials for client management*. +. Click *Save*. + +[IMPORTANT] +Direct update and delete only apply to clients created *after* you enable this feature. Clients created before that do not have the required registration data and cannot be updated or deleted directly through Anypoint Platform. + +=== Implementing Hooks for Non-Supported IdPs + +For IdPs that don't support RFC 7592 (for example, Okta), Anypoint Platform provides hooks so you can intercept outbound calls and implement your own update and delete API logic. Point the client registration URL to an application under your control rather than directly at the IdP. + +These examples show the PUT and DELETE requests that Anypoint Platform makes. This is an example of the payload for a PUT (update) request: ---- @@ -119,13 +137,9 @@ Authorization: Bearer access-token * 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. +* Only the *Client Registration URL* and *Authorization Header* come from what is configured in the OIDC *Client Provider*. The `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: +This example shows the DELETE request header: ---- DELETE /oauth2/connect/register/{{client_id}} @@ -134,13 +148,15 @@ 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. +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 a 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. +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 outbound update to the external IdP (or your interception application) is successful. Using this parameter ensures that the view Anypoint Platform has of the client application is current, even if there are communication issues. -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. +If you don't use the `force` parameter, when updating an external client application via the Anypoint Platform API, Anypoint Platform first attempts the outbound update (either directly to the IdP or to your interception application) and then updates its internal records only if that outbound update is successful. For more information, see https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/console/method/%237020/[Access Management API] documentation. @@ -151,9 +167,9 @@ For more information, see https://anypoint.mulesoft.com/exchange/portals/anypoin 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. +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 https://datatracker.ietf.org/doc/html/rfc8414#section-3[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. +If the client provider supports https://datatracker.ietf.org/doc/html/rfc8414#section-3[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 From e084ee093e62b4c425d6409693447fe075ec022e Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Thu, 19 Mar 2026 08:22:11 -0700 Subject: [PATCH 2/8] Minor tweaks --- .../ROOT/pages/configure-client-management-openid-task.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/modules/ROOT/pages/configure-client-management-openid-task.adoc b/modules/ROOT/pages/configure-client-management-openid-task.adoc index beaab0ec..7ee41683 100644 --- a/modules/ROOT/pages/configure-client-management-openid-task.adoc +++ b/modules/ROOT/pages/configure-client-management-openid-task.adoc @@ -95,7 +95,7 @@ For Okta, the Okta admin must assign the dynamically generated clients to a user Anypoint Platform supports lifecycle management (create, update, and delete) of dynamically registered OAuth2 clients for any IdP that supports the RFC 7592 web standard (such as ForgeRock). For these IdPs, Platform supports and persists the per-client registration token (for example, `registration_access_token` and `registration_client_uri`) returned by the IdP for each newly created client, so you can update and delete those clients directly through Anypoint Platform. This capability is optional; you can use it or keep existing behavior (for example, hooks). Backward compatibility is maintained. -For IdPs that do not support RFC 7592, Anypoint Platform provides hooks so you can implement API calls that are particular to your IdP. +For IdPs that don't support RFC 7592, Anypoint Platform provides hooks so you can implement API calls that are particular to your IdP. [[enable-direct-client-management]] === Enable Direct Client Management @@ -108,9 +108,9 @@ To enable direct client updates and deletions for RFC 7592-compliant IdPs: . Click *Save*. [IMPORTANT] -Direct update and delete only apply to clients created *after* you enable this feature. Clients created before that do not have the required registration data and cannot be updated or deleted directly through Anypoint Platform. +Direct update and delete only apply to clients created *after* you enable this feature. Clients created before that don't have the required registration data and can't be updated or deleted directly through Anypoint Platform. -=== Implementing Hooks for Non-Supported IdPs +=== Implement Hooks for Non-Supported IdPs For IdPs that don't support RFC 7592 (for example, Okta), Anypoint Platform provides hooks so you can intercept outbound calls and implement your own update and delete API logic. Point the client registration URL to an application under your control rather than directly at the IdP. From a2c5f34ca51729b667d89d47b66b1f2f9a9beb58 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Mon, 6 Apr 2026 09:10:55 -0700 Subject: [PATCH 3/8] Edits --- ...nfigure-client-management-openid-task.adoc | 52 ++++++++++++------- 1 file changed, 32 insertions(+), 20 deletions(-) diff --git a/modules/ROOT/pages/configure-client-management-openid-task.adoc b/modules/ROOT/pages/configure-client-management-openid-task.adoc index 7ee41683..703fa1d0 100644 --- a/modules/ROOT/pages/configure-client-management-openid-task.adoc +++ b/modules/ROOT/pages/configure-client-management-openid-task.adoc @@ -50,7 +50,7 @@ Enables deletion of clients created with this integration. 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+`. * *Use registration credentials for client management* + -For IdPs that support the RFC 7592 web standard (such as ForgeRock), check this box to enable direct updates and deletions of dynamically registered client applications through Anypoint Platform. See <> for steps to enable this after your client provider is configured. +Check this box to enable lifecycle management (update and delete) of dynamically registered client applications through Anypoint Platform. When enabled, the system automatically adapts to your IdP's capabilities. If the IdP returns `registration_access_token` and `registration_client_uri` (per RFC 7592), these credentials are used for direct client management. Otherwise, the existing mechanism is used. See <> for configuration steps. . In *Authentication Method*, complete the information for the type of authentication to use for this client provider: * *Authorization Header* + @@ -93,14 +93,18 @@ For Okta, the Okta admin must assign the dynamically generated clients to a user [[manage-dynamic-client-registration-and-lifecycle-updates]] == Manage Dynamic Client Registration and Lifecycle Updates -Anypoint Platform supports lifecycle management (create, update, and delete) of dynamically registered OAuth2 clients for any IdP that supports the RFC 7592 web standard (such as ForgeRock). For these IdPs, Platform supports and persists the per-client registration token (for example, `registration_access_token` and `registration_client_uri`) returned by the IdP for each newly created client, so you can update and delete those clients directly through Anypoint Platform. This capability is optional; you can use it or keep existing behavior (for example, hooks). Backward compatibility is maintained. +Anypoint Platform supports lifecycle management (create, update, and delete) of dynamically registered OAuth2 clients. When you enable the *Use registration credentials for client management* option, Anypoint Platform automatically adapts to your IdP's capabilities: -For IdPs that don't support RFC 7592, Anypoint Platform provides hooks so you can implement API calls that are particular to your IdP. +* If your IdP returns `registration_access_token` and `registration_client_uri` (as specified in RFC 7592), Anypoint Platform persists these credentials and uses them for direct client updates and deletions through the standard RFC 7592 endpoints. -[[enable-direct-client-management]] -=== Enable Direct Client Management +* If your IdP doesn't return these registration credentials, Anypoint Platform uses the existing client management mechanism, which allows you to intercept and handle update and delete requests according to your IdP's specific API requirements. -To enable direct client updates and deletions for RFC 7592-compliant IdPs: +This adaptive approach ensures that client management works regardless of whether your IdP fully implements the RFC 7592 standard. Backward compatibility is maintained for existing configurations. + +[[enable-client-management]] +=== Enable Client Management + +To enable lifecycle management for dynamically registered clients: . Navigate to *Access Management* and click *Client Providers*. . Select your configured client provider. @@ -108,15 +112,22 @@ To enable direct client updates and deletions for RFC 7592-compliant IdPs: . Click *Save*. [IMPORTANT] -Direct update and delete only apply to clients created *after* you enable this feature. Clients created before that don't have the required registration data and can't be updated or deleted directly through Anypoint Platform. +Client management only applies to clients created *after* you enable this feature. Clients created before enabling this setting don't have the required registration data and can't be updated or deleted through Anypoint Platform. + +=== How Client Management Works + +When you enable client management, Anypoint Platform handles update and delete operations based on what your IdP provides during client registration. -=== Implement Hooks for Non-Supported IdPs +* *For IdPs that support RFC 7592:* ++ +If your IdP returns `registration_access_token` and `registration_client_uri` during client registration (such as ForgeRock), Anypoint Platform automatically uses these credentials to make direct RFC 7592-compliant API calls for updates and deletions. -For IdPs that don't support RFC 7592 (for example, Okta), Anypoint Platform provides hooks so you can intercept outbound calls and implement your own update and delete API logic. Point the client registration URL to an application under your control rather than directly at the IdP. +* *For IdPs with custom APIs:* ++ +If your IdP doesn't return RFC 7592 registration credentials (such as Okta), you can implement custom logic by pointing the *Client Registration URL* to an application under your control. This application can intercept Anypoint Platform's outbound calls and translate them to your IdP's specific API format. -These examples show the PUT and DELETE requests that Anypoint Platform makes. +*Example PUT (update) request that Anypoint Platform sends:* -This is an example of the payload for a PUT (update) request: ---- PUT /oauth2/connect/register/{{client_id}} Accept: application/json @@ -134,12 +145,8 @@ Authorization: Bearer access-token "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 the OIDC *Client Provider*. The `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 the DELETE request header: +This is an example of the DELETE request that Anypoint Platform sends: ---- DELETE /oauth2/connect/register/{{client_id}} @@ -147,16 +154,21 @@ 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 a particular provider. +* The `Authorization:` header is included only if you configured the *Authorization Header* under Advanced settings. +* The `client_id` request parameter matches the `client_id` in the PUT request payload. +* The `token_endpoint_auth_method` is always `client_secret_basic`. +* Only the *Client Registration URL* and *Authorization Header* come from your OIDC Client Provider configuration. +* The `client_name` in the request maps to the `name` field on the inbound side. + +Your interception application receives these requests and translates them to the appropriate API calls for your specific IdP. === 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 outbound update to the external IdP (or your interception application) is successful. Using this parameter ensures that the view Anypoint Platform has of the client application is current, even if there are communication issues. +Use the optional `force` parameter to update Anypoint Platform's internal client application records, regardless of whether the outbound update to the external IdP (or your interception application) is successful. Using this parameter ensures that Anypoint Platform's view of the client application is current, even if there are communication issues. -If you don't use the `force` parameter, when updating an external client application via the Anypoint Platform API, Anypoint Platform first attempts the outbound update (either directly to the IdP or to your interception application) and then updates its internal records only if that outbound update is successful. +If you don't use the `force` parameter, Anypoint Platform first attempts the outbound update (either directly to the IdP or to your interception application via the configured Client Registration URL) and then updates its internal records only if that outbound update is successful. For more information, see https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/console/method/%237020/[Access Management API] documentation. From 813a41156cb2df3ace1a05141ee8430e0894c597 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Mon, 6 Apr 2026 09:18:52 -0700 Subject: [PATCH 4/8] SuperAgent edits --- .../configure-client-management-openid-task.adoc | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/modules/ROOT/pages/configure-client-management-openid-task.adoc b/modules/ROOT/pages/configure-client-management-openid-task.adoc index 703fa1d0..b65eb039 100644 --- a/modules/ROOT/pages/configure-client-management-openid-task.adoc +++ b/modules/ROOT/pages/configure-client-management-openid-task.adoc @@ -12,7 +12,7 @@ include::partial$include-nav-steps-org-admin.adoc[] include::partial$include-nav-client-providers.adoc[] . 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*: +. Enter information for *Dynamic Client Registration*: * *Issuer* + URL that the OpenID provider asserts is its trusted issuer. @@ -36,7 +36,7 @@ These are examples of client registration URLs, which are determined by your cli 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. +Anypoint Platform makes an HTTP call to the configured OIDC endpoints. If there is no response within the configured timeout period, the HTTP call times out. + .. Select *Advanced Settings* for these options: * *Disable server certificate validation* @@ -50,7 +50,7 @@ Enables deletion of clients created with this integration. 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+`. * *Use registration credentials for client management* + -Check this box to enable lifecycle management (update and delete) of dynamically registered client applications through Anypoint Platform. When enabled, the system automatically adapts to your IdP's capabilities. If the IdP returns `registration_access_token` and `registration_client_uri` (per RFC 7592), these credentials are used for direct client management. Otherwise, the existing mechanism is used. See <> for configuration steps. +Enables lifecycle management (update and delete) of dynamically registered client applications through Anypoint Platform. When enabled, Anypoint Platform automatically adapts to your IdP's capabilities. If the IdP returns `registration_access_token` and `registration_client_uri` (per RFC 7592), these credentials are used for direct client management. Otherwise, the existing mechanism is used. . In *Authentication Method*, complete the information for the type of authentication to use for this client provider: * *Authorization Header* + @@ -108,7 +108,7 @@ To enable lifecycle management for dynamically registered clients: . Navigate to *Access Management* and click *Client Providers*. . Select your configured client provider. -. Under the *Advanced settings* section, check the box for *Use registration credentials for client management*. +. Under the *Advanced settings* section, select *Use registration credentials for client management*. . Click *Save*. [IMPORTANT] @@ -128,6 +128,7 @@ If your IdP doesn't return RFC 7592 registration credentials (such as Okta), you *Example PUT (update) request that Anypoint Platform sends:* +[source,http] ---- PUT /oauth2/connect/register/{{client_id}} Accept: application/json @@ -148,6 +149,7 @@ Authorization: Bearer access-token This is an example of the DELETE request that Anypoint Platform sends: +[source,http] ---- DELETE /oauth2/connect/register/{{client_id}} Host: identity.example.com @@ -208,5 +210,5 @@ You can select the Refresh Token grant type only if you have also selected the A * https://docs.pingidentity.com/archive/[OpenAM 13.5 Developer's Guide, Procedure 14.4 To Register a Relying Party Dynamically] * https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/Client/[Okta OpenID Connect, Dynamic Client Registration] * https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/[Okta OpenID Connect & OAuth 2.0 API] -* https://docs.pingidentity.com/archive/[AM 5 OAuth 2.0 Guide, 3.1. OAuth 2.0 Client and Resource Server Endpoints] +* https://backstage.forgerock.com/docs/am/5/oauth2-guide/#rest-api-oauth2-client-endpoint[AM 5 OAuth 2.0 Guide, 3.1. OAuth 2.0 Client and Resource Server Endpoints] * https://help.salesforce.com/s/articleView?id=001115835&type=1[How to reset secrets for client applications when using external client management] From 3c04a566599c8de4bfc9f939ca03b7127fc8f99b Mon Sep 17 00:00:00 2001 From: Valkyrie Hunter Date: Mon, 6 Apr 2026 09:38:25 -0700 Subject: [PATCH 5/8] Apply suggestions from code review Co-authored-by: Isaac Eldridge --- .../ROOT/pages/configure-client-management-openid-task.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/modules/ROOT/pages/configure-client-management-openid-task.adoc b/modules/ROOT/pages/configure-client-management-openid-task.adoc index b65eb039..fdad5c70 100644 --- a/modules/ROOT/pages/configure-client-management-openid-task.adoc +++ b/modules/ROOT/pages/configure-client-management-openid-task.adoc @@ -1,6 +1,6 @@ = Configuring OpenID Connect Client Management -Configure an external OpenID Connect (OIDC) identity provider (IdP) to handle client management for your Anypoint Platform APIs. Anypoint Platform supports IdPs that implement the OpenID Connect Dynamic Client Registration (DCR) standard; Salesforce, Okta, and OpenAM (v14 for OpenAM) are explicitly supported. This allows API portals to dynamically register client applications with your chosen external IdP when requesting access. +Configure an external OpenID Connect (OIDC) identity provider (IdP) to handle client management for your Anypoint Platform APIs. Anypoint Platform supports IdPs that implement the OpenID Connect Dynamic Client Registration (DCR) standard, including Salesforce, Okta, and OpenAM (v14 for OpenAM). This allows API portals to 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. @@ -85,7 +85,7 @@ URL where the user authenticates and grants OpenID Connect client applications a 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. +After this is successfully configured, you can use API Manager to apply the OpenID Connect OAuth Token Enforcement policy to your API Gateways. 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. @@ -112,7 +112,7 @@ To enable lifecycle management for dynamically registered clients: . Click *Save*. [IMPORTANT] -Client management only applies to clients created *after* you enable this feature. Clients created before enabling this setting don't have the required registration data and can't be updated or deleted through Anypoint Platform. +Client management only applies to clients created after you enable this feature. Clients created before enabling this setting don't have the required registration data and can't be updated or deleted through Anypoint Platform. === How Client Management Works From 2b77a1e7f9f55ae85fb010366de4f29768487cd1 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Wed, 8 Apr 2026 17:00:43 -0700 Subject: [PATCH 6/8] syntax correction --- .../ROOT/pages/configure-client-management-openid-task.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/ROOT/pages/configure-client-management-openid-task.adoc b/modules/ROOT/pages/configure-client-management-openid-task.adoc index fdad5c70..d72896ac 100644 --- a/modules/ROOT/pages/configure-client-management-openid-task.adoc +++ b/modules/ROOT/pages/configure-client-management-openid-task.adoc @@ -181,9 +181,9 @@ For more information, see https://anypoint.mulesoft.com/exchange/portals/anypoin 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. +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 https://datatracker.ietf.org/doc/html/rfc8414#section-3[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. +If the client provider supports https://datatracker.ietf.org/doc/html/rfc8414#section-3[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 From 5870ab246de7304611a2f09ee4d31e4398633d2a Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Mon, 20 Apr 2026 15:38:15 -0700 Subject: [PATCH 7/8] Duc's review feedback --- .../ROOT/pages/configure-client-management-openid-task.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/ROOT/pages/configure-client-management-openid-task.adoc b/modules/ROOT/pages/configure-client-management-openid-task.adoc index d9cb19bb..7b533afa 100644 --- a/modules/ROOT/pages/configure-client-management-openid-task.adoc +++ b/modules/ROOT/pages/configure-client-management-openid-task.adoc @@ -50,7 +50,7 @@ Enables deletion of clients created with this integration. 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+`. * *Use registration credentials for client management* + -Enables lifecycle management (update and delete) of dynamically registered client applications through Anypoint Platform. When enabled, Anypoint Platform automatically adapts to your IdP's capabilities. If the IdP returns `registration_access_token` and `registration_client_uri` (per RFC 7592), these credentials are used for direct client management. Otherwise, the existing mechanism is used. +When enabled, Anypoint Platform automatically uses RFC 7592 registration credentials if your IdP provides them during client registration. If the IdP returns `registration_access_token` and `registration_client_uri`, these credentials are used for direct client management. Otherwise, the existing client management mechanism is used. . In *Authentication Method*, complete the information for the type of authentication to use for this client provider: * *Authorization Header* + @@ -95,7 +95,7 @@ For Okta, the Okta admin must assign the dynamically generated clients to a user Anypoint Platform supports lifecycle management (create, update, and delete) of dynamically registered OAuth2 clients. When you enable the *Use registration credentials for client management* option, Anypoint Platform automatically adapts to your IdP's capabilities: -* If your IdP returns `registration_access_token` and `registration_client_uri` (as specified in RFC 7592), Anypoint Platform persists these credentials and uses them for direct client updates and deletions through the standard RFC 7592 endpoints. +* If your IdP returns `registration_access_token` and `registration_client_uri` (as specified in RFC 7592), Anypoint Platform persists these credentials and uses them for direct client updates and deletions through the standard RFC 7592 endpoints. For more information, see https://www.rfc-editor.org/rfc/rfc7592.html[OAuth 2.0 Dynamic Client Registration Management Protocol]. * If your IdP doesn't return these registration credentials, Anypoint Platform uses the existing client management mechanism, which allows you to intercept and handle update and delete requests according to your IdP's specific API requirements. From 8c8efdbd4be00ace501b87dc6f809b9ac1ce51ce Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Mon, 20 Apr 2026 16:16:50 -0700 Subject: [PATCH 8/8] Duc's Review --- .../pages/configure-client-management-openid-task.adoc | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/modules/ROOT/pages/configure-client-management-openid-task.adoc b/modules/ROOT/pages/configure-client-management-openid-task.adoc index 7b533afa..1811b7de 100644 --- a/modules/ROOT/pages/configure-client-management-openid-task.adoc +++ b/modules/ROOT/pages/configure-client-management-openid-task.adoc @@ -104,7 +104,7 @@ This adaptive approach ensures that client management works regardless of whethe [[enable-client-management]] === Enable Client Management -To enable lifecycle management for dynamically registered clients: +To enable the registration credentials option: . Navigate to *Access Management* and click *Client Providers*. . Select your configured client provider. @@ -112,11 +112,15 @@ To enable lifecycle management for dynamically registered clients: . Click *Save*. [IMPORTANT] -Client management only applies to clients created after you enable this feature. Clients created before enabling this setting don't have the required registration data and can't be updated or deleted through Anypoint Platform. +==== +For consistent client management behavior, create a new client provider when using the *Use registration credentials for client management* option. + +Anypoint Platform captures and saves registration credentials only for clients created after you enable this option. Clients created before enabling this option continue using the existing client management mechanism, while new clients automatically use RFC 7592 credentials if your IdP provides them. This can result in different management behaviors within the same client provider. +==== 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. -When you enable client management, Anypoint Platform handles update and delete operations based on what your IdP provides during client registration. +When you enable the *Use registration credentials for client management* option, Anypoint Platform uses the `registration_access_token` and `registration_client_uri` credentials if your IdP returns them during client registration. If your IdP doesn't return these credentials, Anypoint Platform uses the existing client management mechanism. * *For IdPs that support RFC 7592:* +