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.

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

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.

Konnect Dev Portal supports a variety of the most widely adopted identity provider (IdP) for Dynamic Client Registration (DCR):

• Auth0
• Azure
• Curity
• Okta

If your third-party IdP is not on this list, 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.

 
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.