Calling Azure Functions via Azure API Managment (APIM) from Browser Resident MSAL.js clients & APIM Subscription Keys

Question

Calling Azure Functions via Azure API Managment (APIM) from Browser Resident MSAL.js clients & APIM Subscription Keys

Siegfried Heintze 1,741

Background:

This is a follow on question to https://learn.microsoft.com/en-us/answers/questions/1381782/how-to-add-subscription-to-consumption-mode-azure. I see that when I use the portal to create an APIM & API I get an all-access-subscription (as described here: https://learn.microsoft.com/en-us/azure/api-management/api-management-subscriptions#all-access-subscription ) and when I use az apim create --name $serviceName --resource-group $rg --publisher-name $pub --publisher-email $email

I don't get such a subscription and either way my javascript (authenticated with MSAL.js) AJAX call can call to my azure function works.

In addition to having customers call my Azure Functions via my APIM, I would like to give them the option to use an existing client that I provide such as a browser resident javascript client.

How to implement Vendor (where I am the vendor) Supplied Javascript Clients?

If I am supplying a browser resident javascript client for my customers to call my Azure Functions via my APIM and I'm using an Azure Static Web Site with my javascript source code stored in a Github repo, how do I store the api subscription key?

I suppose I could store it (the subscription key) in a key vault but regardless of where I store it, it still has go into the javascript source code, correct?
How do I get the subscripiton key into the github resident source code? Do I just hard code it and commit & push to github? I thought this approach to pushing secrets to github repos was highly discouraged! And what if the subscription key changes? How do I write a github action that inserts the new subscription key into the deployed javascript code?
If this subscription key is embedded in the browser resident source code, is it possible to securely post the client on a public web site? I'm thinking no because anyone could extract the subscription key from the javascript!
Since I'm already using <validate-jwt> in the APIM policies as per https://learn.microsoft.com/en-us/azure/api-management/howto-protect-backend-frontend-azure-ad-b2c, how could I add an APIM policy that would expand the claims and determine if current REST call is coming from a paying customer? I could create and store a GUID in an AzureAD extension claim or use a standard claim (mabye the [http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier] claim -- is this unqiue?) and have the APIM policy search a list of paid customers in a cosmos db for his/her unique claim and reject non-paying customers? Is there an example of how to do this somewhere? I think this would solve the problem and give me the benefit of the APIM's ability to shield my azure functions from DOS attacks (for example).

Thanks again for your help!

Siegfried

Answer 1

Thomas Meads 1,506

Hi,

I believe what you are looking for is products which allows a user (authenticated via OAuth or similar) to be given access to a specific set of APIs based on their user group. You can find out more about it here: https://learn.microsoft.com/en-us/azure/api-management/monetization-support.

Storing any kind of secret in an SPA is not possible because as you say someone could just access the key. Hence why the oauth authorization code flow exists.

Hope this helps.

Siegfried Heintze 1,741 Reputation points

2023-10-29T17:17:51.5066667+00:00
Thanks!

Please explain how that link (https://learn.microsoft.com/en-us/azure/api-management/monetization-support) solves my problem of monetizing an azure function that accommodates SPAs. Perhaps you could point to a specific paragraph.

I think I found my answer here: By adding a custom (or extension) attribute (or claim) unique to paying customers and adding a corresponding required claim to my validate-jwt policy ( https://learn.microsoft.com/en-us/azure/api-management/validate-jwt-policy#policy-statement) in my API I could reject non-paying customers. Now Azure AD B2C has a nice user profile feature that allows the users to update some of their claims (including my custom extension claims) in a nice dialog. If I disable this profile editing feature so that users could not edit their own profile, would this be effective and secure?

The problem with this approach is that users could no longer update their attributes like their zip code or phone number. Is there a way I could allow my B2C users to edit all other attributes but not edit my "paid-customer" attribute?
Thomas Meads 1,506 Reputation points

2023-11-05T13:10:34.04+00:00
Hi,

The link I sent explains the monetisation of APIM which sounds like exactly what you're doing. To do this you need to:

Add Azure B2C as a auth provider to your developer portal so that APIM knows the users you have and they can login

Setup products which the users will 'subscribe' too

Integrate the payment method into the developer portal so users can only access what they pay for. Either via delegation which you can read about here: https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-setup-delegation or using the REST API with a custom integration https://learn.microsoft.com/en-us/rest/api/apimanagement/#rest-operation-groups

It however sounds like you are set on your way of doing this. I would read over both the original document and the two additional docs I have sent. If you feel these do not fit with your scenario then a custom flow from B2C or similar will likely be the only option.

Q3 - I believe the only way for a user to update attributes are to make them available through a user flow. Therefore if you don't include it in the update user info flow then it will only be updatable through the portal/REST API.

Hope this helps.
Siegfried Heintze 1,741 Reputation points

2023-11-06T18:54:44.4633333+00:00

I believe most of my customers are going to want to use the Angular (browser resident javascript) web page I will be providing and a small minority of customers will want to create their own clients.

Can a protected product and subscription keys (required for protected products -- correct?) work with Azure AD B2C that gives users the option of using existing browser resident javascript clients that I provide? If I embed the product key in the javascript, then I am giving it away to everyone. I supposed I could automatically email the product key to customers that pay but then how would they use the javascript client? Would they be required to manually edit the javascript code and add the key themselves? That does not sound very friendly.

However, if I use custom attributes (claims) then I could add the custom attribute to indicate that they are a paying customer and automatically reject non-paying customers via the APIM validate-jwt policy.

Maybe I could automate this when I receive a credit card payment ... I'll check into that later.

So it seems to me that protected products are not helpful for browser resident javascript clients in B2C scenarios. Do you agree?

If you don't agree, then please explain because I'm missing something.

Calling Azure Functions via Azure API Managment (APIM) from Browser Resident MSAL.js clients & APIM Subscription Keys

1 answer

Activity