CODEWITHSUNDEEP
azureazure-active-directoryazureportalazure-authentication
jarodsmk
jarodsmk

Reputation: 2089

Setup SPA Frontend and Backend as separate Azure AD App Registrations

I have a SPA (Angular) frontend that communicates with a .NET Core backend, where the backend application is configured to have multiple authentication schemes to not only allow for the SPA frontend to authenticate users registered under the current tenant, but also other APIs (which are registered in Azure AD as separate application registrations).

For each environment, I've registered the frontend and the backend as 2 separate applications, and setup the various scopes, exposed APIs, permissions etc to facilitate the necessary communication using the newer MSAL auth code flow (external APIs that communicate with the backend for each environment use a different authentication flow).

Is it advised to have this configuration, or should I instead treat my frontend and backend as a single application registration?

On one hand, I feel that my frontend is simply another application that is communicating with my backend. But on the other, it could be considered part of the same fundamental 'application'.

Any advice would be appreciated.

Upvotes: 4

Views: 2856

Answers (2)

Krur Schak
Krur Schak

Reputation: 47

I think it depends on the architecture of your software.

If you have a multiservice architecture in which each service communicates directly with the app and is integrated, you should always have one app registration per service and a separate one for your app.

However, the whole thing becomes problematic if, for example, you operate role management and want to secure your API routes based on these roles.

In these cases, it makes sense to create a backend for frontend and control the services in the background via client credential flow using the app-specific API.

I would always authorize the backend for frontend with the same AppRegistration as the one for the app. This makes role management easier.

In our use cases, we even have rest services in the background that we link to a BFF and then continue to work with the frontend via GraphQL and websockets for live updates. For live updates between the services, we use the event-driven pattern with EventHub, ServiceBus or, in some cases, Kafka. But none of this is a problem because we use MassTransit as the interface framework.

I myself am a software architect and have more than 10 years of professional experience in web development.

But at the end of the day, it should definitely be a standardized solution for all your web applications.

Upvotes: 0

Sérgio Correia
Sérgio Correia

Reputation: 576

The 2 app registrations is what is normally advised - it helps on a better separation of concepts, making things clearer.

You can also see this on the official MS Samples, where they always provide the steps to register both client and service apps. Check the following example for an Angular SPA and .NET Core API: https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/3-Authorization-II/1-call-api

Upvotes: 5

Related Questions