In this post, I continue to share what I have learned while building a multitenant application by ultilizing Microsoft Identity Framework and SQL role level security. Specifically, I share what I have learned following Microsoft example project and documentations to make authentication works in a multitenant environment.
First, it’s helpful to distinguish between service principal vs application context in the context of multitenancy.
Service Principal vs Application Object
An application object is a unique identifier representing the instance of the application in a tenant which hosts the application (the application’s home tenant).
A service principal is created in every tenant where the app is used. The application object acts as a blueprint to create service principals.
Making the app multitenant means allowing users from multiple Azure AD tenants to authenticate. For this to work, when registering an application in azure, you must choose either “Accounts in any organizational directory”, or “Accounts in any organizational directory and personal Microsoft accounts”.
As a side note, personal account means a Microsoft or Xbox account, and not just any account. For instance, a user will not be able to login with a Gmail account. One way to allow a user with another account type such as Gmail or Yahoo is to add the user as a guest account in your tenant. However, note that adding guest accounts to your tenant may incur additional fees (For more info, see MAU billing model for Azure AD External Identities — Microsoft Entra | Microsoft Docs).
My app follows a typical setup which includes both a single-page web app and a web API. The web app obtains an access token from azure AD to access the web API on behalf of the user, via an authorization code grant with PKCE . In azure AD, I register both applications. Additionally, I configure Expose an API section for the web API, and API permissions for the web app.
In the screenshot below, I define a scope for the web API in the Expose an API section.