Securing APIs with the Most Secure API Management Instance

Question

Securing APIs with the Most Secure API Management Instance

hampton123 1,175

I'm currently utilizing the consumption-based API management service to oversee my Azure Functions, using a self-hosted developer portal from my Azure Storage account. The primary challenge I'm encountering lies in the interaction with Azure Functions, where both B2C login credentials and an APIM subscription key are mandatory.

Considering a transition to higher tiers of APIM, specifically for the convenience of a pre-built developer portal, I've observed a security issue. The JWT token from my B2C user flow doesn't seem to pass through to the function when invoked through APIM's developer portal. Consequently, this leaves only the subscription key as the protective measure for APIs external to the developer portal.

My aim is to opt for the most secure version of the API management service to fortify my APIs. I was wondering whether there's a consensus on the most secure version or if the choice is dependent on individual use-cases and specific requirements.

Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-27T10:04:44.7+00:00

Hi - thanks for the question
I am not sure I understand exactly so you may need to provide some more details here

The official APIM developer portal isn't available in the consumption tier - either as managed or self hosted. Are you "bringing your own" developer portal here (something you've developed)?

In the abstract the developer portal is a place to discover APIs and also offers a "test console" to allow the logged in user access token to be sent with the "test" request - or, in the case of emulating a app to app test (in the case the api is for client credentials) then the developer portal and az portal apim test console will generate a token which can be used. All this based on the oauth configuration that you enter in APIM

if you're using your own dev portal then really this is the same as any other client application (web app) you need to provide ability for the developer user to login then either request an access token to send through APIM based on the logged in user (e.g. exchanged from the id token) or have the client generate an access token towards the API using it's own app registration / identity

The following provides a guide to approaches you can use with APIM (in flight validation or something more complex) https://learn.microsoft.com/en-us/azure/api-management/authentication-authorization-overview

in your question you allude to just using APIM to check the access token as it passes through towards the function
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-27T10:07:42.9266667+00:00

Also you're correct. oauth is prefer for securing the API and ideally the actual back end API should handle the token because in this way it has access to the claims and can implement (where required) fine grain authorization.
The APIM API key is a useful addition here and can be shared across more than one API (for example all APIs in a product)
By itself the API key may not be enough particularly when used with public clients (e.g browser)
hampton123 1,175 Reputation points

2023-12-27T14:02:03.8566667+00:00

Hi Ben Gimblett! Hope you are doing well, thank you for your assistance on my previous API work.

I believe my terminology may be confusing. This is the link to the developer portal tutorial I followed - this is actually a link you sent me for one of my other API systems! In this situation I'm describing the single-page application as my self-hosted developer portal. Sorry for the confusion. I've created HTML in the SPA that acts as a developer portal, showing users their available APIs based on the subscription key they provide as a query parameter when they access my SPA.

I would use the higher tiers of API management to use the pre-built developer portal, however this would only make the subscription key the only form of protection for the APIs, so that's why I am using the SPA or self-hosted portal.

My end-goal here is to just make an API system that is more secure, as having the subscription key publicly accessible (whether it be through query parameters or headers) poses a potential security risk. I'm also confused on the pricing tiers, as usually the tiers that are more expensive would have more security components. From what I can tell, however it appears that the consumption-based tier is more secure. I'm not sure if maybe my understanding is incorrect on the tiers though.

Thank you again for your help and please let me know if any clarification is needed.
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-27T14:42:06.7533333+00:00

OK gotcha !
I think the part that you're confused about is this: The developer portal (as in the component of APIM offered in the tiers above consumption) is really only for discovering and exploring APIs and happens to have a "test console" , for convenience. However, it's important to note that a developer user can "test" the API any way they like. Command line curl or postman as two examples.

The developer portal allows for a developer user to login - because for some customers - they dont want just anyone to browse and test their API catalogue.

The idea is that the developer users (who gain access and can login) will use the developer portal to gain an understanding of the API offered before developing it into their own client application (whatever that may be)

As the APIs they "test" may be secured so the developer portal offers them a way to generate an access token (again this is a convenience. Postman, as an example, does something similar).

On the other hand, you're offering an end user client application which you've already developed and that happens to run in the users browser (as a single page app)

In your app you develop a way for the actual end user (consuming the app) to sign in , that's open id connect, and then optionally behind the scenes the app can acquire a access token to facilitate a call back to the API.

As you say, this is a lot more secure than relying on the API key alone - both together offer a good level of protection

All tiers of APIM support the policy types which allows you to check an access token on the way through and all tiers support managed service identity (and as far as I'm aware) the "credential manager" feature.
In general the premium tier can be considered more secure based on the fact it offers the most control over networking, however this is also the most costly tier.
hampton123 1,175 Reputation points

2023-12-28T14:03:19.04+00:00

Hi Ben Gimblett, thanks for the response!

That makes more sense - so you're essentially saying here that the developer portal is just another test console. You've also confirmed that passing through the token generated by the user logging in via B2C along with the subscription key is also more secure than just passing the subscription key alone. Thank you for the clarification! My confusion must have come from the fact that I assumed that the developer portal would be the main method through which users would consume the APIs.

For this API management system specifically, users will be creating their own B2C accounts. They would be provided with a subscription key to input through the URL however we really want to change that - we don't want the subscription key to be seen or sent to the consumer through email or any visible means even if the key is refreshable. So there would be quite a few users initially accessing the developer portal creating their own login. I'm sure they would also be testing their APIs through the developer portal.

Honestly I would like to use the higher tiers of API management to use the built-in developer portal so then we would not have to provide their subscription key through the URL, however from what I've researched it appears that the token generated on B2C login would not be able to be passed through to the developer portal. So when users log in and try to call their APIs, they wouldn't be able to do it, which is why I'm currently using a SPA with API management. Although consumers will be calling their APIs through other means such as Postman, they would also use our developer portal and the API calls should work.

In this situation, I'm looking for a way to provide a seamless user experience on log-in while also keeping everything secure. How do you think I should approach this issue? Also, what specific networking options do the higher tiers of API management provide? Knowing this information would allow me to make a more informed decision about which tier to go with.

Thank you again for your help!
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-28T14:26:34.7866667+00:00

You can set up the test console in both the APIM blade in the Az portal (all tiers, but obviously only for APIM owners) and " dev portal " in the non consumption tiers (for dev/public users) to generate a token to "test" an API you expose through APIM
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-oauth2
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-28T14:30:18.53+00:00

As you can see you provide the config for the "test console" to be able to generate the token

In effect there's two use cases

(1) where it's going to be an app to app API - in which case you configure a client credentials flow

(2) where the access token is derived from the logged in user - this might be closer to your use case. Keep in mind then, in this case if the user signs into the dev portal with B2C then you setup the oauth config to generate an access token for a b2c user - the dev portal (at runtime) is smart enough to exchange the id token for access token - it's this access token which will then be used "per logged in user" to test the api. Obviously the token is available for you to look at in the "trace" as it's attached as a auth header bearer token to the request context (as is usual)

This means that either way you can trivially inspect the token to check everything is as it should be
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-28T14:31:53.55+00:00

The pricing page shows a feature breakdown. The dev portal has feature parity with "premium" (but is for non prod use only) https://azure.microsoft.com/en-gb/pricing/details/api-management/
hampton123 1,175 Reputation points

2023-12-28T16:26:40.2466667+00:00

Hi Ben Gimblett! Thank you for your prompt and informative response!

I honestly had no idea that you could add a test token to the portal - I was under the impression that you couldn't add it at all, so this will be perfect! So to sum up the steps, basically after I upgrade my APIM tier from consumption to a tier that contains a developer portal I follow the tutorial you linked to add the test token to the developer portal, correct? This seems like exactly what I was looking for. Thank you for the guide, and thank you for linking the pricing page, I'll be sure to give it a look.

I have another query that crossed my mind. In scenarios where users are testing APIs through tools like Postman or accessing information via Data Factory, how would they obtain the Bearer token? I gather that in Data Factory, users might input their credentials (B2C username and password) along with the subscription key from the APIM developer portal for access. However, I'm unsure about the Bearer token. Would my company need to supply it, and are there ways to impose limitations on these tokens?

I hope these questions aren't overwhelming. Your help has been incredibly valuable - thank you in advance!
Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-02T10:15:36.2533333+00:00

Hi -

With regard to the question about access tokens it may be worth doing a bit of reading to solidify your understanding of oauth2. It is not as simple as it sounds but a solid understanding is important.

As you read the links below keep this in mind:

(1) oauth is about authorization not authentication per-se
(2) for real users to use oauth through an app they first need to have "logged in" Or be "authenticated - there's several ways to do this but the most common is via open-id-connect ---- this is what's happening when a real user logs into an app via facebook, google or for you B2C
(3) Also keep in mind that - although not your scenario here which involves real users - oauth also allows for "app to app" or "machine to machine" authentication. This is where there's no chance of using open-id-connect because there is no real user to enter their credentials. In oauth2 the spec has the "client credentials" flow to accomplish this. The "client" is the app which runs without a user and the "credentials" are the "apps" own credentials stored in config which it needs to request an access token to use. In this way an app using client credentials flow is able to request an access token from the authorization server to call a downstream application or API under it's own identity.

When a user logs into an oauth app , say via facebook or google, or B2C they're entering their credentials the first time at the identity provider (following a redirect) and this is via open id connect as explained here https://openid.net/developers/how-connect-works/ if the login is a success the app receives an "id token" and can later use that id token to identity user attributes plus offer it to the authorization server as evidence when requesting an access token on the end users behalf, perhaps needed to call a downstream api.

Also remember that access tokens are "scoped" (so only for the app or api they were requested for and often contain "claims" which further reduce the scope of what the app can ask on behalf of the user) and they're short lived - once expired the app needs to request a new access token from the authorization server.

(From a Developer standpoint modern identity SDKs usually automate token cache, expiry and refresh).

There's a very simple guide to oauth2 here as a primer https://darutk.medium.com/the-simplest-guide-to-oauth-2-0-8c71bd9a15bb
And slightly more involved guide to build on https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth

Finally, B2C keeps a lot of the detail hidden away. The flow actually used depends on the application registration you created and the version of MSAL you're using https://learn.microsoft.com/en-us/azure/active-directory-b2c/tutorial-register-spa. Authcode with PKCE is the one you want. Implicit flow isnt but as you can see you have to explicitly opt into it via the app registration.
Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-02T10:19:43.7233333+00:00

With regard to Data Factory. Data factory would typically run under it's own credentials (as it's a synonymous with a standalone unattended batch process) for example user assigned or system assigned managed identity.

I am not sure if there's connectors which would allow you to use a real user credential that ADF manages (which is possible in some instances with Az Logic Apps for services where only a user credential can be used for example sharepoint)

If the data factory is in a different AAD/Entra tenant to the data source/store then it may be possible to authorize a service principal cross tenant - but i cant really comment on this as I'm not very familiar with the product.

May be worth asking a separate question for Data factory here (tagged for data factory)
hampton123 1,175 Reputation points

2024-01-02T16:32:56.3233333+00:00

Hi Ben Gimblett, thank you for your response! I'll ask a separate question related to data factory at some point.

I've been trying to solidify my understanding of oauth2 based on the links you sent me, thank you for providing research material for me! To make sure I understand what you’re saying on a base level, I want to sum up what oauth2 does. It appears that the bearer token is generated from oauth2 on login - the authorization server (which is B2C in this situation) presents it after the user provides their credentials. Just as you previously stated it authorizes the user to access the application, and what is returned is the access/Bearer token. When you’re stating that the access tokens are “scoped”, you’re saying that they can be controlled to have other limitations, such as their lifetime and behavior (for example, right now my user flow is set up in that the access & id token lifetimes only last 15 minutes, and the web app session lifetime is also 15 minutes).

So assuming that I’ve followed the steps you’ve linked (https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-oauth2) to configure oauth 2.0 user auth, consumers (using their B2C login) will be able to provide an access token through the header of the request in the Azure APIM developer portal.

Regarding my previous questions, it seems that imposing limitations on the tokens is done through B2C, like you and I previously stated with the access tokens being scoped. How would outside users get access tokens without accessing the developer portal? For example, a user wants to use Postman to access one of our APIs – how would the user provide their credentials to obtain the access token? I’ve tried following a tutorial (https://learn.microsoft.com/en-us/azure/active-directory-b2c/access-tokens) however it hasn’t really been working for me – I get redirected to my application and I don’t actually get an access token.

Thank you for your continued assistance!
hampton123 1,175 Reputation points

2024-01-04T19:11:41.6933333+00:00

Hi Ben Gimblett,

I've been attempting to integrate the OAuth 2.0 user authorization into the test portal, however I've ran into an issue. When I log in through B2C in the smaller window that appears on clicking authorization_code, a token is not provided. Instead, it just logs into the developer portal and pulls up the developer portal again inside of the smaller window (details in this forum post). It's not providing the token. What should I do?

Thanks again for your help!
Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-05T08:36:36.5666667+00:00

Hey there - I have been through the tutorial a few times in the past and so I can say that it should work OK, but, you need to be super careful you follow all steps exactly. It's really easy to miss one. I suspect that the app registration is slightly incorrect - possibly the redirect URLs
can you check again you followed all steps exactly to get B2C working on the developer portal using signup-and-sign-in flow
You need to pay particular attention to the claims and also the app registration settings
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-aad-b2c
let me know if you're still stuck after
hampton123 1,175 Reputation points

2024-01-05T16:50:37.0366667+00:00

Hi Ben Gimblett,

I figured it out by redoing the steps! I also had to change the redirect URLs to take in the B2C login rather than the regular MS login, but now it works. Now the OAuth 2.0 user auth has been integrated in the developer portal.

Thank you for all of your assistance!

1 answer

Your answer

Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-27T10:04:44.7+00:00

Hi - thanks for the question
I am not sure I understand exactly so you may need to provide some more details here

The official APIM developer portal isn't available in the consumption tier - either as managed or self hosted. Are you "bringing your own" developer portal here (something you've developed)?

In the abstract the developer portal is a place to discover APIs and also offers a "test console" to allow the logged in user access token to be sent with the "test" request - or, in the case of emulating a app to app test (in the case the api is for client credentials) then the developer portal and az portal apim test console will generate a token which can be used. All this based on the oauth configuration that you enter in APIM

if you're using your own dev portal then really this is the same as any other client application (web app) you need to provide ability for the developer user to login then either request an access token to send through APIM based on the logged in user (e.g. exchanged from the id token) or have the client generate an access token towards the API using it's own app registration / identity

The following provides a guide to approaches you can use with APIM (in flight validation or something more complex) https://learn.microsoft.com/en-us/azure/api-management/authentication-authorization-overview

in your question you allude to just using APIM to check the access token as it passes through towards the function
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-27T10:07:42.9266667+00:00

Also you're correct. oauth is prefer for securing the API and ideally the actual back end API should handle the token because in this way it has access to the claims and can implement (where required) fine grain authorization.
The APIM API key is a useful addition here and can be shared across more than one API (for example all APIs in a product)
By itself the API key may not be enough particularly when used with public clients (e.g browser)
hampton123 1,175 Reputation points

2023-12-27T14:02:03.8566667+00:00

Hi Ben Gimblett! Hope you are doing well, thank you for your assistance on my previous API work.

I believe my terminology may be confusing. This is the link to the developer portal tutorial I followed - this is actually a link you sent me for one of my other API systems! In this situation I'm describing the single-page application as my self-hosted developer portal. Sorry for the confusion. I've created HTML in the SPA that acts as a developer portal, showing users their available APIs based on the subscription key they provide as a query parameter when they access my SPA.

I would use the higher tiers of API management to use the pre-built developer portal, however this would only make the subscription key the only form of protection for the APIs, so that's why I am using the SPA or self-hosted portal.

My end-goal here is to just make an API system that is more secure, as having the subscription key publicly accessible (whether it be through query parameters or headers) poses a potential security risk. I'm also confused on the pricing tiers, as usually the tiers that are more expensive would have more security components. From what I can tell, however it appears that the consumption-based tier is more secure. I'm not sure if maybe my understanding is incorrect on the tiers though.

Thank you again for your help and please let me know if any clarification is needed.
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-27T14:42:06.7533333+00:00

OK gotcha !
I think the part that you're confused about is this: The developer portal (as in the component of APIM offered in the tiers above consumption) is really only for discovering and exploring APIs and happens to have a "test console" , for convenience. However, it's important to note that a developer user can "test" the API any way they like. Command line curl or postman as two examples.

The developer portal allows for a developer user to login - because for some customers - they dont want just anyone to browse and test their API catalogue.

The idea is that the developer users (who gain access and can login) will use the developer portal to gain an understanding of the API offered before developing it into their own client application (whatever that may be)

As the APIs they "test" may be secured so the developer portal offers them a way to generate an access token (again this is a convenience. Postman, as an example, does something similar).

On the other hand, you're offering an end user client application which you've already developed and that happens to run in the users browser (as a single page app)

In your app you develop a way for the actual end user (consuming the app) to sign in , that's open id connect, and then optionally behind the scenes the app can acquire a access token to facilitate a call back to the API.

As you say, this is a lot more secure than relying on the API key alone - both together offer a good level of protection

All tiers of APIM support the policy types which allows you to check an access token on the way through and all tiers support managed service identity (and as far as I'm aware) the "credential manager" feature.
In general the premium tier can be considered more secure based on the fact it offers the most control over networking, however this is also the most costly tier.
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-28T14:26:34.7866667+00:00

You can set up the test console in both the APIM blade in the Az portal (all tiers, but obviously only for APIM owners) and " dev portal " in the non consumption tiers (for dev/public users) to generate a token to "test" an API you expose through APIM
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-oauth2
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-28T14:30:18.53+00:00

As you can see you provide the config for the "test console" to be able to generate the token

In effect there's two use cases

(1) where it's going to be an app to app API - in which case you configure a client credentials flow

(2) where the access token is derived from the logged in user - this might be closer to your use case. Keep in mind then, in this case if the user signs into the dev portal with B2C then you setup the oauth config to generate an access token for a b2c user - the dev portal (at runtime) is smart enough to exchange the id token for access token - it's this access token which will then be used "per logged in user" to test the api. Obviously the token is available for you to look at in the "trace" as it's attached as a auth header bearer token to the request context (as is usual)

This means that either way you can trivially inspect the token to check everything is as it should be
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-28T14:31:53.55+00:00

The pricing page shows a feature breakdown. The dev portal has feature parity with "premium" (but is for non prod use only) https://azure.microsoft.com/en-gb/pricing/details/api-management/
hampton123 1,175 Reputation points

2023-12-28T16:26:40.2466667+00:00

Hi Ben Gimblett! Thank you for your prompt and informative response!

I honestly had no idea that you could add a test token to the portal - I was under the impression that you couldn't add it at all, so this will be perfect! So to sum up the steps, basically after I upgrade my APIM tier from consumption to a tier that contains a developer portal I follow the tutorial you linked to add the test token to the developer portal, correct? This seems like exactly what I was looking for. Thank you for the guide, and thank you for linking the pricing page, I'll be sure to give it a look.

I have another query that crossed my mind. In scenarios where users are testing APIs through tools like Postman or accessing information via Data Factory, how would they obtain the Bearer token? I gather that in Data Factory, users might input their credentials (B2C username and password) along with the subscription key from the APIM developer portal for access. However, I'm unsure about the Bearer token. Would my company need to supply it, and are there ways to impose limitations on these tokens?

I hope these questions aren't overwhelming. Your help has been incredibly valuable - thank you in advance!
Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-02T10:19:43.7233333+00:00

With regard to Data Factory. Data factory would typically run under it's own credentials (as it's a synonymous with a standalone unattended batch process) for example user assigned or system assigned managed identity.

I am not sure if there's connectors which would allow you to use a real user credential that ADF manages (which is possible in some instances with Az Logic Apps for services where only a user credential can be used for example sharepoint)

If the data factory is in a different AAD/Entra tenant to the data source/store then it may be possible to authorize a service principal cross tenant - but i cant really comment on this as I'm not very familiar with the product.

May be worth asking a separate question for Data factory here (tagged for data factory)
hampton123 1,175 Reputation points

2024-01-04T19:11:41.6933333+00:00

Hi Ben Gimblett,

I've been attempting to integrate the OAuth 2.0 user authorization into the test portal, however I've ran into an issue. When I log in through B2C in the smaller window that appears on clicking authorization_code, a token is not provided. Instead, it just logs into the developer portal and pulls up the developer portal again inside of the smaller window (details in this forum post). It's not providing the token. What should I do?

Thanks again for your help!
Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-05T08:36:36.5666667+00:00

Hey there - I have been through the tutorial a few times in the past and so I can say that it should work OK, but, you need to be super careful you follow all steps exactly. It's really easy to miss one. I suspect that the app registration is slightly incorrect - possibly the redirect URLs
can you check again you followed all steps exactly to get B2C working on the developer portal using signup-and-sign-in flow
You need to pay particular attention to the claims and also the app registration settings
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-aad-b2c
let me know if you're still stuck after
hampton123 1,175 Reputation points

2024-01-05T16:50:37.0366667+00:00

Hi Ben Gimblett,

I figured it out by redoing the steps! I also had to change the redirect URLs to take in the B2C login rather than the regular MS login, but now it works. Now the OAuth 2.0 user auth has been integrated in the developer portal.

Thank you for all of your assistance!

Answer 1

Sonny Gillissen 3,751 Volunteer Moderator

Hi hampton123,

Thank you for reaching out on Microsoft Q&A!

If I understand you correctly you've got an APIM set up with an API endpoint pointing to your Azure Function, right? By design Web Apps, which is basically the base layer of an Azure Function, ignore the 'Authorization' header completely. Therefor not showing in the app.

One of the reasons being that it's not a security risk that the Authorization header is ignored, as in a zero-trust principle you would not want Authorization details to pass every hop in the chain. Every resource should do it's own authorization. So =the fact that the subcription key is passed is the actual security risk here.

If you may need the Authorization header, for example if you need the details in the Azure Function for processing and/or validation, you could convert it to a custom header as below:

<set-header name="X-Custom-Authorization" exists-action="override">
   <value>@(context.Request.Headers.GetValueOrDefault("Authorization"))</value>
</set-header>

You can then make your Azure Function look for that specific header, which enables you to get the Authorization header details still, be it with another name. But, as mentioned, bear in mind that passing through security headers is a risk.

Please click “Accept answer” if you find this helpful. Feel free to drop additional queries in the comments below!

Kind regards,

Sonny

hampton123 1,175 Reputation points

2024-01-08T14:57:47.4466667+00:00
Hi Sonny Gillissen, thank you for the response!

For my own understanding, I want to summarize what you just said in your answer - please let me know if my understanding is incorrect.

The subscription key being visible is more of a security risk than the Auth header bearer token being visible because it is visible throughout each part of the API. The Auth header bearer token is only visible when the user logs in so the token is safer to use.

If I need the Auth header bearer token for API/Azure Function processing, then in APIM I can use the policy you posted to pass the token under a different header name. Then when it passes through API Management, the header is renamed to "Authorization" and passes the token to the backend Azure Function.

Is this understanding correct? I've actually made my API Management instance upgrade to the Standard tier in order to access the developer portal, and thanks to Ben Gimblett's assistance, I've integrated not only the subscription key and Auth token to my API Management developer portal. How would I make this more secure, would I need to rename the Auth header like you were previously stating? Thank you in advance!
Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-08T15:55:47.3933333+00:00

Just to add a couple of points, I understood that:

The subscription key is an APIM subscription key (so that does not go further than APIM)

The B2C Access token requested, in the logged in user context, is towards the backend (the actual API) and passes through APIM. It can be checked (as per the zero trust principle mentioned) using a validate token policy

So.....

If you use "easyAuth" (the authorizations tab in app service/functions) then indeed the header is abstracted , using easyauth means the base app service passes a token to the actual customer func/website code within a custom header https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-oauth-tokens

If you're not using easyauth to actually sign in (and I understand @hampton123 your SPA uses B2C to login the end user) then you should not need to worry about the proprietary header used in app service easy auth sign in REF https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization#authentication-flow

Of course you dont have to use easyauth on the server side in App Services (the backend API here) using microsoft identity (MSAL) and not easyauth is fine too and for a lot of customers they choose this for the extra control.

But back to the main point, irrespective, my understanding is that the APIM gateway here should just be checking the token "On the way through" (for defence in depth/zero trust), because the audience is the actual backend API :)
hampton123 1,175 Reputation points

2024-01-08T17:53:24.81+00:00

Hi Ben Gimblett,

Thanks for being super informative! I understand what easyauth is and MSAL, however I'm a bit confused so I'll try to summarize what you said - please let me know if my understanding is incorrect!

Essentially, because I am using B2C to log users in, I don't need to worry about obscuring the header. I do use easyauth for each Azure Function/API to check the tokens, however because users are not logging in via easyauth, my system is okay as is. Is that a correct understanding?
Sonny Gillissen 3,751 Reputation points Volunteer Moderator

2024-01-09T06:01:20.92+00:00
Hi hampton123,

Almost indeed, there are several things playing here:

An authorization header passes the APIM, but is dropped by the backend. If you really need this in the backend, then you need to convert it to a "custom header" to make sure it passes without interference.

As Ben Gimblett correctly explains: in a zero trust principle you do not want credentials (i.e. authorization header) to pass through to the backend, as every step should be authorized. Therefor the APIM should check validity of the authorization header before calling the backend (or dropping connection when invalid).

To make it zero trust, you would want every step in the process to be validated. So the user calling the APIM should have a token checked by the APIM. When valid the APIM calls the backend, but is validated again by the backend. And so on. Every step in the chain has it's own authentication mechanism basically, and every step taken is validated first before continuing to the next stage (that's most secure).

When you pass the authorization header to the backend you're basically skipping the APIM call, which should perform a check first. However, in some cases the APIM may not be able to check the header. When that happens, the header should be passed to the backend still. But since you were referring to an Azure Function, dropping the authorization header on call, you should make it custom.

Please let me know if you want me to elaborate further on any of these topics. Happy to help!
Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-09T11:49:25.7233333+00:00

@Sonny Gillissen for completeness can you expand on "why" to use a "custom header" when using , in this customers example oauth2 with B2C. The function here should be aware of the idp (b2c) either through MS Identity (MSAL) or EasyAuth - so the token should not be dropped and the standard bearer scheme should be fine
Sonny Gillissen 3,751 Reputation points Volunteer Moderator

2024-01-09T12:27:06.0133333+00:00

Sure thing! Web Apps, API Apps and Function Apps (basically almost all "apps" in Azure) drop the Authorization header as they have their own authentication mechanism. For a Function App this is the function key. Multiple authorization types aren't supported.

Therefor, if you have a situation where you're not going to be able to validate the JWT token in the APIM, for example when you have additional requirements that are not supported by APIM, you need to "cover" the Authorization header to a custom one to make sure it passes to the backend.

Off course, this is not ideal. But at some cases not avoidable. The Azure Function could still be part of the APIM policies where the rest is handled, and only extend features, so in that case you might consider passing the Authorization header through still part of the zero trust as you still provide separate and additional authorization to the Azure Function (being the function key). The header is part of the session, so encrypted along with the call entirely, and can from a Function App perspective be seen as an input body.
hampton123 1,175 Reputation points

2024-01-09T15:15:15.5833333+00:00

Hi Sonny Gillissen & Ben Gimblett,

Thank you both for all of the help so far! Honestly this whole conversation has been very illuminating and helped me understand more security aspects of APIM as well as just regular security protocols I should follow.

So allow me to summarize everything up that you have both been talking about, both to verify my own understanding and to provide a quick summary for future readers of the post to read! Please let me know if any of my understanding is incorrect.

To establish a zero-trust policy within the API's system, each step in an API's process must be validated. The presence of an Authorization header introduces a potential security risk as it may not be validated by default, breaching the zero-trust principle. An approach to this issue is to convert the Authorization header into a custom header using APIM's policies. This ensures that the JWT token is explicitly checked and validated by APIM, aligning with the principles of a zero-trust architecture.

I am still a bit confused on when I should use custom headers. When I initially posted this forum post, I was stating that users log in through a SPA using B2C. Now, however, I've upgraded my API management instance to have APIM's built in developer portal, and now OAuth 2.0 has been integrated into it. For APIM's developer portal, would I need to integrate these custom headers? Also if I were to use the SPA instead, would that be when I use the custom headers? Thanks in advance!
Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-09T15:55:56.14+00:00

Hey @Sonny Gillissen - I see where you're coming from. But care is required here. Yes, if you're using easyAuth (and this applies to any app service, not just functions) it will deal with the auth and pass on tokens in an "x-ms-*" header if your code should need it. Keep in mind that easyAuth was originally for web apps and for OIDC not Authz (exactly)

But the point is you can still hit a Function that expects an access token with an Http Trigger from an upstream app - even with easyAuth and provide a standard authorization header with bearer + token value. easyAuth will then validate this as per the config you provide. Nothing gets stripped and no custom header workarounds are required.

Furthermore, if you dont want to use easyAuth (and some customers dont) then you can just as easily use an SDK for example MSAL / MS Identity https://github.com/AzureAD/microsoft-identity-web/wiki/Azure-Functions and leave easyAuth "off"

Finally, yes funcs does provide an "out of the box" auth functionality but this is commonly used when the customer doesn't require easyauth or oauth - and is a simple SaS based on the host keys. Again, you'd not normally want to use both.
Sonny Gillissen 3,751 Reputation points Volunteer Moderator

2024-01-09T16:43:47.2033333+00:00

Ah, check! Yes, you’re right! Wasn’t fully aware of every detail, thanks for elaborating, Ben Gimblett!
hampton123 1,175 Reputation points

2024-01-10T13:59:46.8+00:00

Hi Sonny Gillissen & Ben Gimblett,

Thanks again for your continued assistance! Just to seek further clarification, would I need to create a custom header for my API management service auth token especially considering the recent integration of OAuth 2.0 into the built-in developer portal?
Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-10T14:14:04.9166667+00:00

hey hampton123

in answer to the question in your comment:

In the original example which is the reference point https://learn.microsoft.com/en-us/azure/api-management/howto-protect-backend-frontend-azure-ad-b2c the client SPA app (and remember the "client" could also be a dev portal or tool like postman) is using b2c to log a user in and then the access token is passed through APIM to a function (which is the backend API) and easyauth is used to check the incoming access token

In this case there's no customization required.

The users logs into the client app (running in the browser) through B2C. The access token acquired can then be passed to the backend via APIM as part of a standard authorization header using the bearer scheme. The token can be validated on the way through APIM using a validate token policy and the easyauth component running in context of the function performs the final validation

IF and only IF you need the token in code you can look for it in the x-ms... header easyauth uses to pass the token on to the actual application code

if you dont want to use easyauth because you want more control - you can reference ms identity lib and write some code directly in the function as explained in the link I posted to Sonny above.
hampton123 1,175 Reputation points

2024-01-10T15:10:14.36+00:00

Hi Ben Gimblett,

Thank you for the clarification! It's good to know that no further customization is required.

Again, thank you for your assistance. You and Sonny have been a major help.

Share via

Securing APIs with the Most Secure API Management Instance

1 answer

Your answer