One vs Two App Registrations for an App with Front-End + API?

Question

Scenario

I have a React SPA with a back-end that provides its data. I want people to log in into SPA with their Entra ID identity. There is a single user_impersonation scope exposed by the API for which access token is requested.

The guidance as seen in a number of tutorials and MS Learn resources for the Microsoft Identity Platform seems to be to set up two app registrations:

• one for the SPA (with redirect URLs), and
• one for the API (with exposed scopes, permissions for downstream APIs and app roles).

I see a number of issues with this approach:

• on a logical level, there is only a single app even if it has two components
• overhead with managing two app registrations/enterprise apps instead of one, e.g. in terms of assigning users to it
• app roles defined only on the API registration (as per the recommendation here won't be exposed to the front-end

Questions

1. Can you confirm having two app registrations is an official recommendation for this scenario?
2. If yes, what is the reason to prefer it over one app registration which combines all above configurations (i.e. exposes the user_impersonation scope, defines app roles and redirect URIs - I understand we'd still have ID and access tokens but issued for the same audience)?
3. If not, what would be the recommended alternative configuration with a single app registration?

Answer 1

Hello @metalheart , having 2 app registration is recommended since you could also say that you have 2 applications: a client and an API. The recommendation follows the separation of concerns principle and provides some benefits such as fine-grained security and ease of management. Combining both registrations into one may be a good idea during early development or testing but in the long run it can get messy and prone to security, management and maintenance issues. Let's say you split your dev teams in 2: 1 for your client app and 1 for your api app. You may also want to limit management for each app registration to their belonging team. This won't be possible using only 1 app reg since you cannot limit permissions per user or group per app reg feature: any user with write permissions will be able to update any app reg feature. You may want to implement Conditional Access: SPA authentication requests should be allowed only if coming from a 3 counties or IP ranges but authorization requests from a selected user pool (let's say SPA admins, moderators, etc.) should come from 1 country or IP range and should get prompted for MFA or require a compliant device. This might be doable using 1 app registration but the configuration and maintenance will become harder contradicting the KISS principle.

Keep in mind that an SPA is not as secure as an API (which is why an API can store secrets while the SPA does not) so it's a good idea to target an app registration only for the purpose of authentication but not of authorization. Let's say you want the API to call other APIS such as Microsoft Graph using the OBO flow: With 1 app registration there won't be any need for OBO since any SPA user may directly request an access token for any Microsoft Graph scope. With 2 app registrations there won't be any Microsoft Graph scopes exposed in the SPA app reg, only in the API app reg. SPA app reg will be used for authentication only while API app reg will be used for authorization. Additional authorization policies will be easier to enforce trough the API application code or Entra features such as Conditional Access. Also, and from the infrastructure and security side, having 2 app regs will allow to narrow down who can manage secrets for API-to-API communication, also narrowing down the impact caused by leaked credentials: 1 careless developer may generate and share a SPA app reg secret but it won't be of any use for API to API access.

Let us know if you need additional assistance. If the answer was helpful, please accept it and rate it so that others facing a similar issue can easily find a solution.