Blog
|
Engineering
April 30, 2024
5 min read

Managing Application Auth for Different Audiences

Ella Kuzmenko
Sr. Product Manager, Kong

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:

  1. Create one Auth0 DCR provider
  2. Reuse that DCR provider to create two authentication strategies, one for Flights API v2 that uses read scopes, and one for Scheduling API v2 that uses read and write scopes
  3. Apply those auth strategies to their respective API Product versions

Step 1: Create one Auth0 DCR provider

First, we create our DCR Provider.

We'll do this with a 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.

Step 2: Reuse that DCR provider to create two authentication strategies

Next, create our two application auth strategies with a call to 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": ""
}

Step 3: Apply our newly created auth strategies to their respective API Product versions

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 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 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:

  1. We’ve published the API Product versions so that Flights v2 and Scheduling v2 are now available in our Flights portal
  2. We’ve enabled app registration so our partner developers can actually register for Flights v2 and Scheduling v2 APIs
  3. We’ve enabled the Flight Auth strategy for Flights v2 API and Scheduling Auth strategy for our Scheduling v2 API in our Flight Portal, ensuring our partners consuming different APIs receive the appropriate scopes depending on their access level.

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 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:

  1. We published two API Product versions, each using a unique auth strategy
  2. We created two auth strategies from the same underlying DCR provider which gave us the flexibility to create a unique auth strategy per API Product version
  3. We introduced a new concept called the Portal Product Version, which we can use in the future to manage our Product Version’s auth configs across multiple dev portals

If you’d like to extend this example, I’ll mention a couple of other use cases for Application Auth strategies:

  • Create multiple DCR providers, and apply different auth strategies (using different DCR providers) to different API Product versions in the same Dev Portal
  • Create a DCR, OIDC, and Key Auth authentication strategy and mix and match them to as many API Product versions as you would like
Ella Kuzmenko
Sr. Product Manager, Kong

Recommended posts

Configuring Kong Dedicated Cloud Gateways with Managed Redis in a Multi-Cloud Environment

Engineering

Architecture Overview A multicloud DCGW architecture typically contains three main layers. 1\. Konnect Control Plane The SaaS control plane manages configuration, plugins, and policies. All gateways connect securely to this layer. 2\. Dedicated C

Hugo Guerrero

Leveraging the MCP Registry in Kong Konnect for Dynamic Tool Discovery

Engineering

Tool discovery for AI agents In early agent implementations, tools are often statically configured inside the agent. For example: { "mcpServers": { "weatherServer": { "command": "uv", "args": "run", "weather_serv

Hugo Guerrero

Secure AI at Scale: Prisma AIRS and Kong AI Gateway Now Integrated

Engineering

In today's digital landscape, APIs are the backbone of modern applications, and AI is the engine of innovation. As organizations increasingly rely on microservices and AI-powered features, the API gateway has become the critical control point for man

Tom Prenderville

Modernizing Integration & API Management with Kong and PolyAPI

Engineering

The goal of Integration Platform as a Service (iPaaS) is to simplify how companies connect their applications and data. The promise for the first wave of iPaaS platforms like Mulesoft and Boomi was straightforward: a central platform where APIs, sys

Gus Nemechek

AI Voice Agents with Kong AI Gateway and Cerebras

Engineering

Kong Gateway is an API gateway and a core component of the Kong Konnect platform . Built on a plugin-based extensibility model, it centralizes essential functions such as proxying, routing, load balancing, and health checking, efficiently manag

Claudio Acquaviva

Farewell Ingress NGINX: Explore a Better Path Forward with Kong

Engineering

"To prioritize the safety and security of the ecosystem, Kubernetes SIG Network and the Security Response Committee are announcing the upcoming retirement of Ingress NGINX . Best-effort maintenance will continue until March 2026. Afterward, there w

Justin Davies

Kong Simplifies Multicloud Cloud Gateways with Managed Redis Cache

Product Releases

Managed Redis cache is a turnkey "Shared State" add-on for Kong Dedicated Cloud Gateways. It is designed to combine the performance of an in-memory data store with the simplicity of a SaaS product. When you spin up a Dedicated Cloud Gateway in Kong

Amit Shah

Ready to see Kong in action?

Get a personalized walkthrough of Kong's platform tailored to your architecture, use cases, and scale requirements.

Get a Demo