Dev Portal Dynamic Client Registration

Dynamic Client Registration (DCR) in Konnect Dev Portal allows an application in the Dev Portal to register as a client with an Identity Provider (IdP). This outsources the issuer and management of application credentials to a third party, as the IdP returns a client identifier and the registered client metadata. This enables OpenID Connect (OIDC) features that the IdP supports. Dev Portal DCR adheres to RFC 7591.

In Dev Portal, you can create and use multiple DCR configurations. You can configure DCR by doing the following:

After you publish an API that’s linked to a Gateway Service with a DCR application authentication strategy applied, developers can register an application with your API in Dev Portal. Dev Portal registers that application as a client in the IdP through DCR and displays the returned credentials to the developer. Requests to your API succeed only when the client presents valid credentials and the application holds a registration for the linked Service.

The following diagram shows how this DCR flow works:

 
sequenceDiagram
    actor Developer
    Developer->> +Dev Portal: Creates an application
    Dev Portal->>+IdP: Creates an application
    IdP->>-Dev Portal: Returns client metadata, Client ID, and secrets
    Dev Portal->>Dev Portal: Saves application record in database with ONLY Client ID mapping
    Dev Portal->>-Developer: Returns application creation success with client ID and secret
  

DCR support in Konnect provides multiple methods by which applications can be authenticated using industry-standard protocols. These methods include:

• Client credentials grant: Authenticate with the client ID and secret provided to the application.
• Bearer tokens: Authenticate using a token requested from the IdP’s /token endpoint.
• Session cookie: Allow sessions from either client credentials or bearer tokens to persist via cookie until an expiration.

Each method is available when using the following DCR identity providers:

• Okta
• Curity
• Azure
• Auth0
• Kong Identity

Note: When using DCR, each application automatically receives a client ID and secret. These credentials can be used to authenticate directly with services using the client credentials grant, or to obtain an access token from the identity provider when using the bearer token authentication method.

Authentication with bearer tokens

You can obtain a bearer access token by requesting it from the IdP’s /token endpoint:

The following table describes the token endpoints for IdPs:

Authentication with session cookie

After successfully authenticating using either client credentials or a bearer access token, you can use session cookie authentication to authenticate subsequent requests without including the original credentials. To use this method, ensure that your identity provider is configured to send session cookie response headers.

If your third-party IdP isn’t natively supported, you can still use your IdP with Konnect by using a custom HTTP DCR bridge. This HTTP DCR bridge acts as a proxy and translation layer between your IdP and DCR applications in the Dev Portal. When a developer creates a DCR application in the Dev Portal, Konnect calls your HTTP DCR bridge which can translate the application data into a suitable format for your third-party IdP, and add additional functionality such as making API calls to other systems as part of the DCR flow.

 
sequenceDiagram
    actor Developer
    participant Konnect Dev Portal
    participant HTTP DCR Bridge
    participant IdP
    Developer->>Konnect Dev Portal: Create application
    Konnect Dev Portal->>HTTP DCR Bridge: POST Create application
    HTTP DCR Bridge->>IdP: POST Create application
    IdP--)HTTP DCR Bridge: 200 OK and credentials
    HTTP DCR Bridge->>Konnect Dev Portal: Create application response (with credentials from IdP)
    Konnect Dev Portal->>Developer: Show credentials
  

Figure 1: This diagram illustrates how an HTTP DCR bridge creates an application in an IdP when a developer submits an application in the Konnect Dev Portal. First, the developer creates an application in the Dev Portal, which triggers the portal to send the application details to the HTTP DCR bridge. The bridge then sends a POST create application request to the IdP. If the IdP successfully processes the request, it returns a 200 status code along with the credentials for the developer’s application. These credentials are then displayed to the developer in the Dev Portal.

Configure custom DCR using the Konnect Dev Portal DCR Handler

To use an unsupported IdP with DCR, you must implement an API that conforms to the Konnect Dev Portal DCR Handler spec. Kong provides an example reference implementation in the Konnect Dev Portal DCR Handler repository. This is an example HTTP DCR bridge implementation and is not meant to be deployed in production. We encourage you to use this implementation as a guide to create your own implementation.

Any request that does not return a 2xx status code is considered a failure and will halt the application creation process in your Konnect Dev Portal.

Dev Portal developers can manage their application credentials through their applications page without needing a Dev Portal admin’s assistance. Developers can maintain multiple active credentials, allowing them to assign different credentials to each service consuming their application and revoke credentials as needed. This is supported by the following IdPs:

• Entra
• Okta
• Custom HTTP DCR bridge

HTTP DCR bridge credential rotation: To make sure that their developers have access to the credential API endpoints, Dev Portal admins must ensure that the HTTP DCR bridge supports credential rotation based on the provided API spec. The number of active credentials supported per application is determined by the identity provider configured in the HTTP DCR bridge.

Dev Portal admins can view credential IDs by opening an application in Konnect and checking its Credentials tab. Application credential values are not visible from Konnect, and Dev Portal admins cannot add or revoke credentials directly from Konnect.

Developers can view credential IDs by opening an application in their Dev Portal, and checking its Credentials tab. Application credential values are not visible after creation. Developers can revoke credentials directly from the Credentials tab.

Rotate a credential

When developers need to replace a credential with a new one, they can rotate the credential manually through an application’s configuration page in their Dev Portal:

1. In your Dev Portal, click your profile and select My applications.
2. Open an application.
3. Click the Credentials tab.
4. Click New Credential.
5. Copy and save the secret somewhere safe. You won’t see this key again.
6. Click Copy and close to save.
7. Test the new credential by using it in the same workflow as the old one.
8. When you’re ready, delete the old credential:
   1. Click the Credentials tab.
   2. Click the action menu for the old credential.
   3. Select Revoke.
   4. Enter revoke.
   5. Click Revoke.

Developers can also manage their application credentials using the Portal API.