Dynamic Client Registration (DCR) within Konnect Dev Portal allows applications created in the portal to automatically create a linked application in a third-party Identity Provider (IdP).
This outsources the issuer and management of application credentials to a third party, allowing for additional configuration options and compatibility with various OIDC features provided by the IdP. Konnect offers the flexibility to create multiple DCR configurations.
DCR support in Konnect provides multiple methods by which applications can be authenticated using industry-standard protocols. These methods include:
/token endpoint.Each method is available when using the following DCR identity providers:
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.
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:
|
Vendor |
Endpoint |
Body |
|---|---|---|
| Auth0 |
POST https://$REGION.auth0.com/oauth/token
|
{ "grant_type": "client_credentials", "audience": "$YOUR_AUDIENCE" }
|
| Curity |
POST https://$YOUR_CURITY_DOMAIN/oauth/v2/oauth-token
|
{ "grant_type": "client_credentials" }
|
| Okta |
POST https://$OKTA_SUBDOMAIN.okta.com/oauth2/default/v1/token
|
{ "grant_type": "client_credentials" }
|
| Azure |
POST https://login.microsoftonline.com/$YOUR_TENANT_ID/oauth2/v2.0/token
|
{ "grant_type": "client_credentials", "scope": "https://graph.microsoft.com/.default" }
|
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):
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 applicationrequest to the IdP. If the IdP successfully processes the request, it returns a200status code along with the credentials for the developer’s application. These credentials are then displayed to the developer in the Dev Portal.
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.
What connections and protocols are involved between Dev Portal and our organization when DCR is enabled?
Konnect will make HTTP requests to the IdP for DCR. The details of the request are IdP-specific.
What connections and protocols are involved when a custom HTTP DCR bridge is configured for a custom IdP?
Kong uses HTTPS to transmit events to the domain you’ve provided and includes a key that can be used on your custom handler implementation to verify the events are from Konnect.