How do I set up Okta OIDC Client Provider with Private Key JWT using the Two App pattern in the OKTA Application Console?
Two distinct Okta applications are required for this integration:
App A (The Manager): A "Service" app using Private Key JWT. Used by Anypoint to create and manage client applications.
App B (The Inspector): A "Service or Web" app using Client Secret. Used by the API Gateway to validate (introspect) tokens at runtime.
Create App: Navigate to Applications > Create App Integration > API Services.
Name: MuleSoft-Client-Manager.
Authentication: In the General tab, click Edit on Client Credentials. Select Public key / Private key.
Keys: Click Add key > Generate new key. Save the Private Key (PEM) locally (you will need this for Anypoint). The Public Key is saved in Okta automatically.
Disable DPoP: In General Settings, ensure Require Demonstrating Proof of Possession (DPoP) is unchecked (MuleSoft does not support DPoP).
Permissions (Scopes): Go to the Okta API Scopes tab. Grant the okta.clients.register okta.clients.read (and okta.clients.manage) scope. [If you need client app deletion/secret rotation etc ability for your IDP]
Admin Role: Go to the Admin Roles tab. Assign the Application Administrator role. Note: Custom roles often fail to authorize client creation via API.
REFERENCE: OKTA SUPPORT DOCS: https://devforum.okta.com/t/dynamic-client-registration-permission-required/28056/8
Contact Okta Support for more help on this topic.
Create App: Navigate to Applications > Create App Integration > OIDC - OpenID Connect > Web Application.
Name: MuleSoft-Token-Introspection.
Authentication: Ensure Client Secret is selected.
Credentials: Note the Client ID and Client Secret.
Navigate to Access Management > Client Providers > Add Client Provider > OpenID Connect Dynamic Client Registration.
Issuer: https://{yourOrg}.okta.com (Use the Org URL, not a custom server).
Client Registration URL: https://{yourOrg}.okta.com/oauth2/v1/clients.
Method: Select Use OAuth2 private key jwt.
Token Client ID: Enter the Client ID of App A (The Manager).
Token Client Private Key: Paste the PEM Private Key generated in Step 1.
Token Client API Scopes: Enter okta.clients.register okta.clients.read (or okta.clients.manage).
Client ID: Enter the Client ID of App B (The Inspector).
Client Secret: Enter the Client Secret of App B (The Inspector).
Authorize URL: https://{yourOrg}.okta.com/oauth2/v1/authorize.
Token URL: https://{yourOrg}.okta.com/oauth2/v1/token. Crucial: Must use the Org URL to honor the admin scopes.
https://devforum.okta.com/t/the-authorization-server-id-is-invalid-error-while-trying-api-endpoints-using-postman/19420/5#:~:text=First%20off%2C%20if,own%20management%20endpoints.
https://devforum.okta.com/t/dynamic-client-registration-with-custom-authorization-server/15426/4
Token Introspection URL: https://{yourOrg}.okta.com/oauth2/v1/introspect.
Click Create.
Navigate to Exchange, select an API asset, and click Request Access.
Creates a new application(also, on OKTA side) . If successful, the Client Provider is correctly configured to manage applications in Okta.
Once the Client Provider is created, you must enforce it on your API.
Navigate to API Manager: Select your specific API instance.
Policies: Click Policies > Add Policy.
Select Policy: Choose OpenID Connect access token enforcement.
Select API Settings: Select the Okta provider you just created.
To verify the setup, we will simulate a developer requesting access and then calling the API.
Step A: Get a Token (Simulating the App) Use the credentials of a client application created via Anypoint Exchange (not the Manager or Inspector apps).
Method: POST
URL: https://integrator-2487462.okta.com/oauth2/aus103lfwgxipichu698/v1/token (Your Custom Auth Server)
Authorization: Basic Auth
Username: {Client ID of the App created in Exchange}
Password: {Client Secret of the App created in Exchange}
Body (x-www-form-urlencoded):
grant_type: client_credentials
scope: custom_scope
Step B: Call the MuleSoft API
Method: GET (or POST, depending on your API)
URL: https://{your-mule-api-domain}/api/resource
Headers:
Authorization: Bearer {Paste_Access_Token_From_Step_A}
Result: You should receive a 200 OK response.
If you get 401: The policy rejected the token (check Introspection URL match).
If you get 403: The token is valid, but lacks required scopes.
Okta OIDC CP, OAuth2 Private Key JWT, Anypoint Platform, Okta Mule App Client Id
Disclaimer:
This article is just for Informational purpose only. This article involves products and technologies which do not form part of the MuleSoft product set. Technical assistance for such products is limited to this article. Contact Vendor Support for further help/assistance setup required on their product directly.
Summary:
This guide details the configuration of an OIDC Client Provider in MuleSoft Anypoint Platform using the Private Key JWT authentication method. This setup requires the "Two-App Pattern" in Okta to satisfy both the security requirements of the Anypoint Control Plane (Private Key) and the Mule Runtime (Client Secret).
005315457

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.