Managing Application Auth for Different Audiences

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:

We'll get back a response that contains the DCR ID like so:

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:

We get a response like:

For Scheduling API v2:

We get a response like:

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:

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:

And receive the following response:

For Scheduling API v2 we send the following payload:

And receive the following response:

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:

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