MSAL for React frontend & Django backend - Anything helps

Is there a standard practice for MSAL auth when using a separate frontend/backend lagnuage? Should I have both a Public and ConfidentialClient, or just one? I'm confusing myself after reading the docs thoroughly for a couple weeks...

My primary goal is for users to obtain an access token with my client ID as the audience claim so that the django api can validate it (middleware), and then secure an additional set of tokens with MS Graph's default scope so that my backend can make calls to MS Graph (such as sending emails via the mail endpoint).

It seems redundant for react to use msal.js library and the django backend to also use msal since it'll result in two separate token caches... Should I only implement msal into one of them? If so, should I prefer one over the other?

I could use a little guidance in terms of how to structure my msal authentication in my project... Any help would be appreciated, no matter how small/quick it is...

Solution

You have two main approaches, the difference in them is which "side" of the client/server divide is the "boss".

The most common one is client-authoritative, which boils down to the client telling the server what's what in terms of the user's data.

In such a setup, for the scenario you outline, you need MSAL on both sides. @azure/msal-react with a Public application instance (which doesn't store tokens) on the frontend to handle onboarding, pipy-msal with a Confidential application instance on the backend to handle token storage and API calls. This will necessitate collaboration between the frontend and the backend; at a minimum you'll have to transmit either the client secret or a token that can be exchanged for the client secret.

Less common but no less valid is a server-authoritative approach, where the server doesn't accept arbitrary data from the client but instead gathers it on its own. When a user needs to perform onboarding with Azure, the frontend would redirect them to a backend endpoint and handle everything there with no intercommunication between the frontend and the backend. You wouldn't need any Public MSAL application instances for this.

Overview:

Client-authoritative

Pros:

Common flow, so plenty of documentation and examples

Cons:

Requires some small degree of duplication, as you need to talk to Azure endpoints from two separate servers

Server-authoritative

Pros:

Keeps Azure-logic centralized and de-duplicated
Encapsulates Azure-logic so that the frontend doesn't have to care or know about anything Azure-related

Cons:

Requires building user-facing endpoints (with security, authentication, domain access, etc.) outside of the frontend
To some extent requires building backend endpoints (and optionally frontend wrappers) to implement "missing" application logic that otherwise might have been handled by Microsoft's library

Conclusion:

"Standard practice" is an ill term. What is the best choice for you ultimately depends depends on your business needs, your tech-architectural choices, and so on.

But if you're in doubt, chances are you'll fare better with the client-authoritative approach for many reasons. The cons of the server-authoritative approach can be deceivingly complex (depending on aforementioned choices) and for that reason alone it should probably not be undertaken unless you have a really detailed understanding of the whole user-journey on a technical level. The complexity of the client-authorative approach is significantly more stable against architectural choices.