Application authentication strategies

Beta and uses: Kong Gateway Dev Portal

Tags

#authentication #application-registration #beta

Related Resources

SSO reference

Application registration

About Dev Portal Dynamic Client Registration

About OIDC Dynamic Client Registration

Dev Portal developer sign-up

Dev Portal application authentication strategies determine which developers can access which APIs. You can define and reuse multiple authentication strategies for different APIs and Dev Portals. For example:

key-auth: Built-in default
okta-oidc: OpenID Connect with Okta
okta-dcr: Dynamic Client Registration with Okta
auth0-oidc: OpenID Connect with Auth0

Using these, a flexible setup might look like:

Staging Portal
- Weather API v1 → key-auth
- Weather API v2, Maps API v2 → okta-oidc
Production Portal
- Weather API v2 → okta-dcr
- Maps API v2 → auth0-oidc

 
flowchart TB
    subgraph Production Portal
    WeatherAPIv2p["Weather API v2"] --> okta-dcr
    MapsAPIv2-2["Maps API v2"] --> auth0-oidc
    end
    subgraph Staging Portal
    WeatherAPIv2s["Weather API v2"] --> okta-oidc
    MapsAPIv2-1["Maps API v2"] --> okta-oidc
    WeatherAPIv1["Weather API v1"] --> key-auth
    end

Authentication strategies are reusable and can be applied across multiple APIs and Dev Portals.

Developers can only use one auth strategy per application. For example, to register for both Weather v2 and Maps v2 (both use okta-oidc), one application is sufficient. To register for Weather v1 and Weather v2, two applications are required.

Configure the key auth strategy

Key authentication is Konnect’s built-in API authentication strategy. When developers create an application through your Dev Portal, they are automatically issued credentials.

By default, a Key Auth strategy is created for every Dev Portal. If your portal is marked as Private, this strategy is also set as the default in your security settings.

To create an additional key auth strategy:

Navigate to the Application Auth tab in the Dev Portal.
Click New Auth Strategy.
Enter a name (for internal use) and a display name (visible to developers).
Select Key auth as the auth type.
Click Save.

Dev Portal OIDC authentication

OpenID Connect (OIDC) is an open authentication protocol that lets users sign in to multiple sites using one set of credentials. Using the OIDC authentication strategy allows developers visiting your Dev Portal to authenticate using OIDC.

There are two ways to use OIDC with the Dev Portal:

Linking static clients (Self-managed OIDC): Developers bring their own pre-registered application from the IdP and manually link the client ID to their Portal application.
Dynamic Client Registration (DCR): The Dev Portal automatically creates and manages applications in the IdP as developers need them.

The following table compares the two Dev Portal OIDC methods:

Feature	Self-managed OIDC (Static)	DCR OIDC (Dynamic)
App creation in IdP	Manual by developer	Automated by Dev Portal
Client ID management	Manual	Automated
Use case	Full developer control	Streamlined onboarding
IdP support required	Any OIDC IdP	IdP must support DCR

Configure OIDC in Dev Portal

If you don’t have an OIDC auth strategy set up, follow these steps to create one:

Create a new strategy under Application Auth and select OpenID-Connect as the auth type.
Provide a name for internal use and a display name for developers.
Enter the Issuer URL for your OIDC provider.
Define the scopes required by your developers (for example, openid, profile, email).
Set the Credential Claims to match the client ID from your identity provider.
Select the authentication methods you need, such as client_credentials, bearer, or session.
Save the strategy.

Optionally, update the Default Auth Strategy in Settings > Security to use your new OIDC strategy for easier publishing.

OpenID Connect configuration parameters

For more background information about OpenID Connect plugin parameters, see the OpenID Connect plugin configuration reference.

Form Parameter	Description	Required
`Issuer`	The issuer URL from which the OpenID Connect configuration can be discovered. For example: `https://dev-1234567.okta.com/oauth2/default`.	True
`Scopes`	The scopes to be requested from the OpenID Provider. Enter one or more scopes separated by spaces, for example: `open_id` `myscope1`.	False
`Credential claims`	Name of the claim that maps to the unique client id in the identity provider.	True
`Auth method`	The supported authentication method(s) you want to enable. This field should contain only the authentication methods that you need to use. Individual entries must be separated by commas. Available options: `password`, `client_credentials`, `authorization_code`, `bearer`, `introspection`, `kong_oauth2`, `refresh_token`, `session`.	True
`Hide Credentials`	Hide the credential from the upstream service. If enabled, the plugin strips the credential from the request header, query string, or request body, before proxying it. Default: disabled	False
`Auto Approve`	Automatically approve developer application requests for an application. Default: disabled	False

Link static clients with self-managed OIDC

With this model, developers bring their own pre-registered application from the IdP and manually link the client ID to their Portal application. You should use this model if:

You want developers to have full control over their IdP applications.
Your IdP doesn’t support DCR, or you do not want to enable it.
You require manual review or approval of all IdP applications.

Self-managed OIDC follows this workflow:

Developer registers an application directly in the IdP (such as Okta, Auth0, Azure, etc.).
Developer copies the client ID (and secret, if needed).
Developer creates or links an application in the Dev Portal, providing the client ID.
The Dev Portal uses the provided client ID for OIDC authentication.

Note: The Dev Portal doesn’t create or manage IdP applications in this model. All application management is manual and handled by the developer or IdP admin.