Let’s pose a hypothetical scenario. You're the API product owner at the Paris, Texas Regional Airport. You're in charge of two main APIs: Flights API and Scheduling API. Flights API is primarily used by local research institutions that are interested in read-only access to information about departures and arrivals. Scheduling API is primarily used by airline partners who are interested in updating information about their flights and gates. You would like to create similar auth strategies for your different customers, with slightly different permissions based on scopes.
Flights API has read:gate-priority and write:gate-priority scopes while Scheduling API has read:flight-schedule and write:flight-schedule. Research institutions should only receive read:flight-schedule and read:gate-priority scopes. Airline partners should receive both read and write scopes to the flight-schedule and gate-priority resource (i.e. read:flight-schedule, write:flight-schedule, read:gate-priority, and write:gate-priority).
In this scenario, you would like to configure different authentication types for each partner. One authentication strategy will use an Auth0 DCR Provider with read scopes, the other authentication strategy will use an Auth0 DCR Provider with read and write scopes.
We'll walk you through how you can do this with the newly released Application Auth strategies. In this blog, we'll do the following:
First, we create our DCR Provider.
We'll do this with a [POST v2/dcr-providers](https://kong-platform-api.netlify.app/konnect/application-auth-strategies/v2/openapi.yaml/#tag/DCR-Providers/operation/create-dcr-provider)POST v2/dcr-providers call containing our DCR config info. We'll reuse the same DCR Provider for both APIs. For example:
curl --request POST \
--url https://us.api.konghq.com/v2/dcr-providers \
--header 'Authorization: $KPAT' \
--header 'content-type: application/json' \
--data '{
"name": "Auth0 DCR Provider",
"provider_type": "auth0",
"issuer": "https://my-issuer.auth0.com/api/v2/",
"dcr_config": {
"initial_client_id": "abc123",
"initial_client_secret": "abc123xyz098!",
"initial_client_audience": "https://my-custom-domain.com/api/v2/"
}
}'We'll get back a response that contains the DCR ID like so:
{
"created_at": "2024-02-29T23:38:00.861Z",
"updated_at": "2024-02-29T23:38:00.861Z",
"id": "93f8380e-7798-4566-99e3-2edf2b57d289",
"name": "Auth0 DCR Provider",
"provider_type": "auth0",
"issuer": "https://my-issuer.auth0.com/api/v2/",
"dcr_config": {
"initial_client_id": "abc123",
"initial_client_audience": "https://my-custom-domain.com/api/v2/"
},
"active": false
}We'll save our DCR ID (e.g., `93f8380e-7798-4566-99e3-2edf2b57d289`) as we will use it in step two.
Next, create our two application auth strategies with a call to [POST v2/application-auth-strategies](https://kong-platform-api.netlify.app/konnect/application-auth-strategies/v2/openapi.yaml/#tag/App-Auth-Strategies/operation/create-app-auth-strategy)POST v2/application-auth-strategies. The power of these independent auth configs is in the reusability; we created one DCR provider and will be able to reuse it twice as we create two application auth strategies. This is great as we want to create two similar, but slightly different, auth strategies where just the scopes differ.
When we create the application auth strategy, we add the relevant claims (e.g., email, profile, permissions, org_id, etc), scopes, auth methods, and a display name for our auth configs that will be easily understood by the developers in our Flight Portal (e.g., “Flight API Auth”).
Lastly, we'll paste in the DCR ID from step one into each of our auth configs. You'll notice the difference between the two auth configs is that we want to use different scopes (read-only scopes for Flights API v2 and read-and-write scopes for Scheduling API v2).
As we're using DCR, our create app auth strategy calls may look something like the following:
For Flights API v2:
curl --request POST \
--url https://us.api.konghq.tech/v2/application-auth-strategies \
--header 'Authorization: $KPAT' \
--header 'content-type: application/json' \
--data '{
"name": "Auth0 Flight API Auth",
"display_name": "Flight Auth",
"strategy_type": "openid_connect",
"configs": {
"openid-connect": {
"issuer": "https://my-issuer.auth0.com/api/v2/",
"credential_claim": [
"client_id"
],
"scopes": [
"openid",
"email",
"read:flight-schedule",
"read:gate-priority"
],
"auth_methods": [
"client_credentials",
"bearer"
]
}
},
"dcr_provider_id": "93f8380e-7798-4566-99e3-2edf2b57d289"
}'We get a response like:
{
"id": "51012536-41d0-4a94-996b-d451b9e5945f",
"name": "Auth0 Flight API Auth",
"display_name": "Flight Auth",
"configs": {
"openid-connect": {
"issuer": "https://oidc.example.com",
"scopes": [
"openid",
"email",
"read:flight-schedule",
"read:gate-priority"
],
"auth_methods": [
"client_credentials",
"bearer"
],
"credential_claim": [
"client_id"
]
}
},
"dcr_provider": {
"id": "93f8380e-7798-4566-99e3-2edf2b57d289",
"name": "Auth0 DCR Provider",
"provider_type": "auth0"
},
"strategy_type": "openid_connect",
"active": false,
"created_at": "",
"updated_at": ""
}For Scheduling API v2:
curl --request POST \
--url https://us.api.konghq.tech/v2/application-auth-strategies \
--header 'Authorization: $KPAT' \
--header 'content-type: application/json' \
--data '{
"name": "Auth0 Scheduling Auth",
"display_name": "Scheduling Auth",
"strategy_type": "https://my-issuer.auth0.com/api/v2/",
"configs": {
"openid-connect": {
"issuer": "https://oidc.example.com",
"credential_claim": [
"client_id"
],
"scopes": [
"openid",
"email",
"read:flight-schedule",
"write:flight-schedule",
"read:gate-priority",
"write:gate-priority"
],
"auth_methods": [
"client_credentials",
"bearer"
]
}
},
"dcr_provider_id": "93f8380e-7798-4566-99e3-2edf2b57d289"
}'We get a response like:
{
"id": "8343d4f3-83c5-4861-8569-3aa85ca03ae4",
"name": "Auth0 Scheduling Auth",
"display_name": "Scheduling Auth",
"configs": {
"openid-connect": {
"issuer": "https://oidc.example.com",
"scopes": [
"openid",
"email",
"read:flight-schedule",
"write:flight-schedule",
"read:gate-priority",
"write:gate-priority"
],
"auth_methods": [
"client_credentials",
"bearer"
],
"credential_claim": [
"client_id"
]
}
},
"dcr_provider": {
"id": "93f8380e-7798-4566-99e3-2edf2b57d289",
"name": "Auth0 DCR Provider",
"provider_type": "auth0"
},
"strategy_type": "openid_connect",
"active": false,
"created_at": "",
"updated_at": ""
}Now that we have our auth strategies, we'll apply each of these auth strategies to our products using the [POST v2/portals/{portalId}/product-versions](https://kong-platform-api.netlify.app/konnect/portal-management/v2/openapi.yaml/#tag/Portal-Product-Versions)POST v2/portals/{portalId}/product-versions endpoint. This endpoint introduces a new concept called the Portal Product version. This entity maps different auth configurations for your portal product version, depending on the portal they’re published to. This way you can publish the same Product version to multiple portals using entirely different auth configs. When Multiple Portal capability is launched in two months, you'll use the Portal Product version to manage different auth strategies for your different portals.
To use the [POST v2/portals/{portalId}/product-versions](https://kong-platform-api.netlify.app/konnect/portal-management/v2/openapi.yaml/#tag/Portal-Product-Versions)POST v2/portals/{portalId}/product-versions endpoint, we will need the portalId we want to publish to, the product_version_id for each of our product versions, and the auth_strategy_id we wish to attach to that product version in that portal
Here are the values we will be using for our example:
portalId: aa8219fa-aaea-4a89-a780-638eaee20349
Flights API v2 product_version_id: 35ac33d5-c6c9-4c8c-8a7d-d40585d51a93
Scheduling API API v2 product_version_id: bb21545f-0c39-47ab-8c23-9b0ba11e6528
Flights auth_strategy_id: 51012536-41d0-4a94-996b-d451b9e5945f
Scheduling auth_strategy_id: 8343d4f3-83c5-4861-8569-3aa85ca03ae4
Now let’s go ahead and assign our newly created auth strategies for each of our APIs.
For Flights API v2 we send the following payload:
curl --request POST \
--url https://us.api.konghq.tech/v2/portals/aa8219fa-aaea-4a89-a780-638eaee20349/product-versions/ \
--header 'Authorization: $KPAT' \
--header 'content-type: application/json' \
--data '{
"product_version_id": "35ac33d5-c6c9-4c8c-8a7d-d40585d51a93",
"auth_strategy_ids": [
"51012536-41d0-4a94-996b-d451b9e5945f"
],
"publish_status": "published",
"application_registration_enabled": true,
"auto_approve_registration": true,
"deprecated": false
}
'And receive the following response:
{
"created_at": "2024-03-01T22:52:28.074Z",
"updated_at": "2024-03-01T22:52:28.074Z",
"id": "bd8e9714-fb50-4a7c-a694-ea70da1ab970",
"publish_status": "published",
"deprecated": false,
"auto_approve_registration": true,
"application_registration_enabled": true,
"product_version_id": "35ac33d5-c6c9-4c8c-8a7d-d40585d51a93",
"auth_strategy_ids": [
"51012536-41d0-4a94-996b-d451b9e5945f"
]
}For Scheduling API v2 we send the following payload:
curl --request POST \
--url https://us.api.konghq.tech/v2/portals/aa8219fa-aaea-4a89-a780-638eaee20349/product-versions/ \
--header 'Authorization: $KPAT' \
--header 'content-type: application/json' \
--data '{
"product_version_id": "bb21545f-0c39-47ab-8c23-9b0ba11e6528",
"auth_strategy_ids": [
"8343d4f3-83c5-4861-8569-3aa85ca03ae4"
],
"publish_status": "published",
"application_registration_enabled": true,
"auto_approve_registration": true,
"deprecated": false
}And receive the following response:
{
"created_at": "2024-03-01T22:52:28.074Z",
"updated_at": "2024-03-01T22:52:28.074Z",
"id": "f506423a-63dd-4239-b303-8d22f13d20ac",
"publish_status": "published",
"deprecated": false,
"auto_approve_registration": true,
"application_registration_enabled": true,
"product_version_id": "bb21545f-0c39-47ab-8c23-9b0ba11e6528",
"auth_strategy_ids": [
"8343d4f3-83c5-4861-8569-3aa85ca03ae4"
]
}By sending these payloads, here is what we’ve accomplished:
Note: If your API Products are not yet published, you'll need to publish the API Product itself in order for the API Product versions to be published to your portal.
And voila! The research group now has read-only access to Flights API and Scheduling API, whilst partners have read and write access to Flights API and Scheduling API. We can double-check our work with a [GET v2/portals/{portalId}/product-versions](https://docs.konghq.com/konnect/api/portal-management/latest/#/Portal%20Products/list-portal-products)GET v2/portals/{portalId}/product-versions call where we will see our two published portal product versions like so:
{
"data": [
{
"created_at": "2024-03-01T22:52:28.074Z",
"updated_at": "2024-03-01T22:52:28.074Z",
"id": "bd8e9714-fb50-4a7c-a694-ea70da1ab970",
"publish_status": "published",
"deprecated": false,
"auto_approve_registration": true,
"application_registration_enabled": true,
"product_version_id": "35ac33d5-c6c9-4c8c-8a7d-d40585d51a93",
"auth_strategy_ids": [
"51012536-41d0-4a94-996b-d451b9e5945f"
]
},
{
"created_at": "2024-03-01T22:52:28.074Z",
"updated_at": "2024-03-01T22:52:28.074Z",
"id": "f506423a-63dd-4239-b303-8d22f13d20ac",
"publish_status": "published",
"deprecated": false,
"auto_approve_registration": true,
"application_registration_enabled": true,
"product_version_id": "bb21545f-0c39-47ab-8c23-9b0ba11e6528",
"auth_strategy_ids": [
"8343d4f3-83c5-4861-8569-3aa85ca03ae4"
]
}
],
"meta": {
"page": {
"total": 2,
"size": 100,
"number": 1
}
}
}To recap what we accomplished:
If you’d like to extend this example, I’ll mention a couple of other use cases for Application Auth strategies:
The MSK exposure problem Amazon MSK brokers live in private subnets by default. That's the right default. Kafka's protocol wasn't designed for untrusted networks — it has no concept of rate limiting, no built-in field-level encryption, and its ACL
The core of this system rests on a foundational principle: currency-specific credit balances are never directly modified. Rather than a simple mutable counter, which is prone to race conditions and opaque manual adjustments, we utilize a comprehensi
What You'll Build To explore the new integration, I'll build a realistic API platform workflow using Konnect, Kong Gateway, and Insomnia. By the end of this tutorial, I'll have: A Konnect Control Plane (KongAir Dev) A local Kong Gateway Data Pl
Built on top of Kong API Gateway, the Kong AI Gateway is designed to address key challenges in enterprise AI adoption. Modern AI applications rarely rely on a single model; instead, they orchestrate multiple GenAI providers, agent frameworks, Age
Traditional agreement processes were slow and heavily manual. Documents were often created in office tools, shared through email, printed, signed physically, and stored across multiple systems. Tracking the status of agreements required manual follo
The Problem: As organizations adopt agentic AI, a massive gap exists between compliance approvals and network reality. Often, AI governance is relegated to manual reviews and "paper approvals," meaning network firewalls and gateways have no context
Most teams handle field-level data protection with client-side interceptors — code that has to live in every producer and consumer, in every language, maintained by every team that touches the topic. Renaming a topic means a migration project. And