Add Microsoft SSO to Your App

Microsoft sign-in runs on Entra ID using OpenID Connect (OIDC), the same standards-based flow as other modern providers. Your app redirects to Microsoft, the user signs in with the work account they already use, and Microsoft returns a signed ID token your server verifies.

The decision that makes Microsoft different is tenant scope. You choose whether to accept one specific organization, any Microsoft work or school account, or personal accounts as well. That choice shapes who can sign in and how you validate the token's issuer.

For how this fits with sessions and roles, see the SaaS authentication guide. With The Bridge, Microsoft SSO is a toggle on the hosted login box: register the app in Entra ID, paste the client ID and secret, pick the tenant scope, and the rest is handled.

The flow follows OpenID Connect. You redirect to Microsoft with your client ID, the scopes you need, a redirect URI, and a state value. Entra ID authenticates the user, applies any conditional-access policies the organization enforces, and redirects back with a code your server exchanges for tokens.

Verification is where the tenant model shows up. You validate the ID token signature against Microsoft's published keys, then check the issuer and audience, and for a single-organization app you confirm the tenant ID claim matches the tenant you expect. Skip that and a multi-tenant token could let the wrong organization in.

The Bridge performs this verification, including the tenant checks, and returns one normalized user object.

The manual path lives in the Azure portal and your verification code:

• An Entra ID app registration with the right redirect URIs and a client secret or certificate you rotate on a schedule.
• The tenant-scope choice wired into token validation, so a single-org app rejects tokens from other tenants and a multi-tenant app validates each issuer correctly.
• Admin consent for the permissions you request, coordinated with the customer's IT.

The reason enterprises want this is governance. Identity stays central: when an employee is disabled in Entra ID, they lose access to your app without you doing anything. That is exactly why security teams ask for it in procurement.

The Bridge handles the registration wiring, token validation, and tenant checks, so you get the governance without the Azure plumbing.

Offer a fallback. Internal tools may be all-Microsoft, but a SaaS product usually has users who do not sign in with a work account, so keep another method available.

Set tenant scope on purpose. Allowing any Microsoft account is convenient for a consumer-leaning product; locking to a single organization is what an internal tool wants. Choose per app rather than by default.

Not every enterprise is on Microsoft. Many bring Okta, Google Workspace, or another provider, so if you sell into enterprise, plan to connect any SAML identity provider as well. With The Bridge, Microsoft SSO and other providers land on the same user model, so adding the next one is configuration, not a new integration.