Application authentication strategies

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.

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:

1. In the Konnect sidebar, click Dev Portal.
2. In the Dev Portal sidebar, click Application Auth.
3. Click New authentication strategy.
4. In the Name field, enter a name for internal use.
5. In the Display name field, enter a name for external use that is visible to developers.
6. From the Authentication Type, select “Key-Auth”.
7. (Optional) To configure an expiration time for the key, do the following:
   1. Click Advanced configuration.
   2. In the Key Names field, enter a name for your key that will display in the API request header.
   3. Enable Key expiration policy.
   4. In the Key expires after dropdown menu, select the number of days, weeks, or years after which the key will expire.
8. Click Save.

Once you’ve configured the key auth strategy, you must apply it to your Dev Portal, API packages, and APIs. For a complete tutorial, see Enable key authentication for Dev Portal apps.

Key expiration notes:

• If you configure key expiration and edit the expiration, any pre-existing keys will expire at the previous configuration value. For example, if you configure keys to expire in 14 days and then edit it so that they expire in 7 days, any pre-existing keys will expire in 14 days.
• You can customize the emails users receive when a key is about to expire and when a key expires by navigating to your Dev Portal, clicking Portal Editor, and then clicking the Email icon in the sidebar.

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:

Configure OIDC in Dev Portal

For a step-by-step guide about how to configure OIDC with Okta, see Enable self-managed OIDC auth with Okta in Dev Portal.

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

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

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:

1. Developer registers an application directly in the IdP (such as Okta, Auth0, Azure, etc.).
2. Developer copies the client ID (and secret, if needed).
3. Developer creates or links an application in the Dev Portal, providing the client ID.
4. 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.

The default auth strategy of a Dev Portal will apply to any APIs that are published to that Dev Portal. You can adjust the strategy through Dev Portal security settings.

If you want to override the default auth strategy, you can configure a different auth strategy on a per API or per API package basis.

1. In the Konnect sidebar, click Dev Portal.
2. Click your Dev Portal.
3. From the Actions dropdown menu, select “Settings”.
4. Click the Security tab.
5. From the Authentication strategy dropdown menu, select the auth strategy you want to set as the default.
6. Click Save changes.

After configuring an auth strategy, you can apply it to APIs.

1. In the Konnect sidebar, click Catalog.
2. In the Catalog sidebar, click APIs.
3. Click the API you want to apply the auth strategy to.
4. Depending on the API’s publication status, do one of the following:
   1. Unpublished: Click Publish API.
   2. Published: Click the more options menu and then click Edit publication.
5. From the Authentication strategy dropdown menu, select the auth strategy you want to apply to the API.
6. Click Save.

To enforce auth strategies on an app, you must link your API to a Gateway Service.

After configuring an auth strategy, you can apply it to API packages.

1. In the Konnect sidebar, click Catalog.
2. In the Catalog sidebar, click APIs.
3. Click the API packages tab.
4. Click the API package you want to apply the auth strategy to.
5. Click the Portals tab.
6. Depending on the API’s publication status, do one of the following:
   1. Unpublished: Click Publish API.
   2. Published: Click the more options menu and then click Edit publication.
7. From the Authentication strategy dropdown menu, select the auth strategy you want to apply to the API.
8. Click Save.

To enforce auth strategies on an app, you must link your API package to a Gateway Service.