Background: Back in Aug 2021 I had a terrible time enhancing a simple Azure AD demo ( https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/blob/master/4-WebApp-your-API/4-2-B2C/README.md ) to run in side a Kubernetes replica set. After filing a support ticket in Oct 2021, I as able to make the sample work in late Feb 2022 by abandoning the nuget package for Redis Caching in favor of the StackExchange nuget package for Redis caching with the guidance from Microsoft support (it took months of staring at deep stack traces with many Microsoft Support Specialists). Questions: As I recently learned from Ben ( https://learn.microsoft.com/en-us/answers/questions/587801/how-to-run-nodejs-in-kubernetes-replica-set-with-a ) the problem was because MSAL uses data protection. Can I assume that a cache that implements the data protection is also required for Azure Container Apps, App Service Scale sets (for function apps and web apps) if I am authenticating with MSAL? As I explained above, the solution was to use a cache that supported the data protection feature required by MSAL which (at the time) did not include the Microsoft Nuget package for Redis. So which caches support MSAL data protection requirement today? What about these caches: https://learn.microsoft.com/en-us/aspnet/core/performance/caching/distributed?view=aspnetcore-7.0 ? This list does not include the cosmos cache ( https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/session-state-and-caching-provider ) and makes me worried that maybe the cosmos cache does not support data protection. It would sure be nice if those last two web pages explicitly stated that they support (or don't support) the data protection feature required by MSAL. Thanks Siegfried

@Siegfried Heintze sorry for the delay in replying - I read your follow-up question, did some more digging and then some things came up and I forgot to post it Anyway apologies for that I peer checked the following internally with the Identity folks. Question: How does Microsoft.Identity.Web (wrapping MSAL) work in the scenario where a feature is encrypting (so keys are required) and the app is distributed? References: This doc does a fairly good job of outlining how to enable a distributed cache https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-net-token-cache-serialization?tabs=aspnetcore#distributed-token-caches The troubleshooting guide gives a further clue https://github.com/AzureAD/microsoft-identity-web/wiki/Token-Cache-Troubleshooting#im-using-encryption-and-im-getting-deserialization-errors - quoting: "Be aware that distributed systems do not share encryption keys by default!" Today, it isn't the [token] cache that matters (you should be able to use any cache) neither should the hosting platform matter (with the exception that some of the Data protection API functions are OS specific, where this is the case it's called out in the docs). The App [host] itself need to be configured for data protection and as part of that you also configure a key store which should be accessible for all instances of the app. As I understand it the distributed key storage and the token cache are different concerns - the key storage is only required where a feature using encryption is turned on (an example might be csrf mitigations for asp net web apps) For more information see this doc, I've linked the specific section for docker - hope this helps https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-7.0#persisting-keys-when-hosting-in-a-docker-container

What are the special considerations for using MSAL & Azure Active Directory with regard to Caching, Data Protection & Auto Scalers?

Accepted answer

Ben Gimblett 4,540 Reputation points Microsoft Employee

2023-07-26T09:05:56.99+00:00

@Siegfried Heintze sorry for the delay in replying - I read your follow-up question, did some more digging and then some things came up and I forgot to post it

Anyway apologies for that

I peer checked the following internally with the Identity folks.

Question: How does Microsoft.Identity.Web (wrapping MSAL) work in the scenario where a feature is encrypting (so keys are required) and the app is distributed?

References:

This doc does a fairly good job of outlining how to enable a distributed cache https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-net-token-cache-serialization?tabs=aspnetcore#distributed-token-caches

The troubleshooting guide gives a further clue https://github.com/AzureAD/microsoft-identity-web/wiki/Token-Cache-Troubleshooting#im-using-encryption-and-im-getting-deserialization-errors - quoting: "Be aware that distributed systems do not share encryption keys by default!"

Today, it isn't the [token] cache that matters (you should be able to use any cache) neither should the hosting platform matter (with the exception that some of the Data protection API functions are OS specific, where this is the case it's called out in the docs). The App [host] itself need to be configured for data protection and as part of that you also configure a key store which should be accessible for all instances of the app.

As I understand it the distributed key storage and the token cache are different concerns - the key storage is only required where a feature using encryption is turned on (an example might be csrf mitigations for asp net web apps)

For more information see this doc, I've linked the specific section for docker - hope this helps
https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-7.0#persisting-keys-when-hosting-in-a-docker-container
Please sign in to rate this answer.
Siegfried Heintze 1,906 Reputation points

2023-07-27T18:18:26.77+00:00

Very interesting. Thanks. Help me understand https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-net-token-cache-serialization?tabs=aspnetcore#quick-summary where it says "If you request tokens for users in a production application, use a distributed token cache".

Question #3:

Does "production" mean auto-scalers? Couldn't you have a production web application running without an autoscalar (like K8 replica set) and have a single instance of the web application? If so, why would you need a distributed cache?

Does "production" mean auto-scalers? Couldn't you have a production web application running without an autoscalar (like K8 replica set) and have a single instance of the web application? If so, why would you need a distributed cache?

Does "production" mean auto-scalers? Couldn't you have a production web application running without an autoscalar (like K8 replica set) and have a single instance of the web application? If so, why would you need a distributed cache?

Also, how does this work if you are using an azure static web site (and maybe a CDN) for a Javascript/Angular (using MSAL.js) or Blazor WebASM or MAUI front end talking to an in-process Azure Function (as demonstrated here: https://learn.microsoft.com/en-us/azure/api-management/howto-protect-backend-frontend-azure-ad-b2c). Do these issues with token caching and key storage become non-issues? I've never used a scale set for an azure function but apparently it is supported: https://learn.microsoft.com/en-us/samples/azure-samples/azure-scale-set-smart-downscale/smart-scaling-for-azure-scale-set-with-azure-functions/

Since in-process azure functions can authenticate (Using the validate JWT policy in Azure API Mgt as demonstrated in the in the above APIM tutorial) but cannot store state, I don't think token caches and data protection are meaningful, even in a scale set. Is this correct?

Thanks,

siegfried

Ben Gimblett 4,540 Reputation points Microsoft Employee

2023-08-01T13:51:09.8266667+00:00

It makes sense to cache , but no, you dont need a distributed cache unless you're going to scale out. And arguably then you only need it where consistency is required (e.g. for shared keys and keys in this context are only needed where features require cryptography)

Certainly for dotnet - out of the box MSAL offers an in memory cache for tokens which should be suitable for many scenarios https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-net-token-cache-serialization?tabs=aspnetcore

For JS MSAL uses browser local storage REF https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-spa-acquire-token?tabs=javascript2

There are scenarios for APIM where you may acquire a token in the context of an incoming call - but then it's beholden on you to use the APIM cache policy for performance and to reduce latency REF this example https://github.com/Azure/api-management-policy-snippets/blob/master/examples/Backend%20OAuth2%20Authentication%20With%20Cache.policy.xml (Also noting here that the new-ish "authorizations" feature of APIM abstracts token acquisition and storage for SaaS integration scenarios which is a simpler end user implementation)

RE Functions horizontal scaling

Functions consumption: The autoscaling is taken care for you (as it's "serverless") the function can scale within host, within a compute node and across nodes up to the limits of the service

Functions Elastic Premium: This is prefer for event driven functions and scales horizontally based on the trigger auto-scaler logic also known as a "scale controller" (e.g. for Service Bus trigger that would include queue depth) REF https://learn.microsoft.com/en-us/azure/azure-functions/event-driven-scaling?tabs=azure-cli . Scale limits apply.

Functions on app service: you use the app service inflate and deflate rules you define. ASEv3 hosting means that functions can typically scale out more (bigger limit), but ASEv3 scale out isn't as fast as regular app service.

For hosting funcs on K8S or AKS you would typically use KEDA to provide for event driven scaling https://learn.microsoft.com/en-us/azure/azure-functions/functions-kubernetes-keda

Siegfried Heintze 1,906 Reputation points

2023-08-15T21:15:29.65+00:00

Thanks for those great responses. They are very helpful.

So I was reviewing https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/introduction?view=aspnetcore-7.0#problem-statement where I believe it is saying (correct me if I am wrong) that if I want to store sensitive information in the form of claims in my JWT that is used for authentication and authorization, I probably want to use the ASP.NET data protection feature that is built into MSAL.NET (but not MSAL.js). This will prevent dishonest employees from illicitly extracting claims in the cache.

However, since I had trouble (in the past) configuring data protection and shared caches for AKA replica sets, why not just use browser resident javascript front ends with MSAL.js and forget about the shared caches and data protection?

Since I suspect the answer is that storing JWTs in the browser is less secure, I was hoping you could elaborate.

Also, I believe browser resident javascript applications do not store client secrets but Razor and Blazor server apps do. (Do Razor & Blazor Server apps still require client secretes in .NET7?)

So I'm guessing that authenticating Razor & Blazor server apps have some additional benefits & capabilities? What might these be?

Thanks

Siegfried

Ben Gimblett 4,540 Reputation points Microsoft Employee

2023-08-21T13:52:38.1533333+00:00

Blazor (which includes razor markup) is a SPA and as such it's a public client - in context of oauth then the recommended flow for a SPA would be auth-code + PKCE (not implicit)
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-app-types#single-page-apps-javascript

Public clients are not trusted clients (e.g. a server side web app) and you should generally assume that anything "secret" in a public client could be compromised

But, back to the main point :)

from a MS Identity and MSAL perspective , the way i think about data protection is a more modern version of machine keys. At some point when dealing with auth/authz and cookies (and the various best practices for security) you are inevitably going to require encryption and that means (for a distributed system) you need shared key access.
In the bad old days this often meant literally copying and pasting machine keys across web farm nodes.

Things are a little more sophisticated now and the ASP NET CORE DAPI (data protection) offers full control over configuring the "key ring" used - and as discussed above, MSAL/MS Identity are using the DAPI (therefore implicitly that same default OR user provided configuration.)

The following page is worth reading as it summarises a lot of the info you need to know when thinking about applying modern auth (using MS Identity/MSAL) in a distributed environment
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/web-farm?view=aspnetcore-7.0#dependent-components and includes a sub section on dependent components (e.g. features which may require encryption and therefore access to keys on the server side)

That features part is super important - you need to understand where Data protection may need to apply - it's not going to be limited to the front end / backend type - it's going to come down to the features used (either those defaulted, or the ones you opt into).

The default behaviour (where an asp net core app will look for DAPI keys) is doc here https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/default-settings?view=aspnetcore-7.0#key-management - overriding this should be as simple as providing the configuration (for example using Az Key Vault for key storage) https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-7.0

I would presume that the section on docker hosting would apply equally to AKS/K8S https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-7.0#persisting-keys-when-hosting-in-a-docker-container

** On OAUTH tokens + sensitive data
*
For my own personal view; back in the day when the oauth2 spec was being decided there was quite a big controversy over the fact that the spec would rely on transport security (SSL/TLS) and the token would not be encrypted, only encoded and signed.

Today most of the customers I speak to are using JWS (encoded,signed json web tokens) , there is of course also the possibility with some IDP of using "opaque" tokens , aka JWE's. Sometimes this requires the addition of an "introspection" endpoint where the client is not able to decrypt/validate the token by itself.

(Even though most people use JWS most of the time, almost everyone refers to it as JWT)

If you look at the community for advice you're going to find comment that more or less fits into the following two buckets
(1) Dont include PII/secrets in token claims
(2) if you must, encrypt the token
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

What are the special considerations for using MSAL & Azure Active Directory with regard to Caching, Data Protection & Auto Scalers?

0 additional answers

Your answer