Enterprise solution for implementing SSO

Question

If a user with a specific Microsoft account (email) has been invited to access an application which he has accepted. But then later tries to login using his other M365 account, how can we then make sure he doesn't get access to the application? the solution should involve dynamic checking as these users are not manually added to the tenant where the application is resgistered

Answer 1

Configure the application and its Microsoft Entra integration so that access is tied to the specific invited identity and tenant, and enforce this at token-validation time rather than relying on manual user management.

Key elements:

1. Use Microsoft Entra ID as the only IdP and disable local/bypass accounts
   Ensure the app can only be accessed via Microsoft Entra ID and not via local or backup credentials:
   • Identify whether the app allows local credentials or backup sign-in methods.
   • In the app configuration, disable any option that lets users bypass SSO and sign in with local/app-specific accounts.
   • Test by using an InPrivate browser session and confirming that the only sign-in path is via Microsoft Entra ID. This ensures that all access decisions are based on Microsoft Entra tokens for a specific account.
2. Require assignment and control who can access the Enterprise app
   In the resource tenant where the app is registered as an Enterprise application:
   • Set User assignment required? = Yes on the Enterprise application.
   • Only assign the specific invited user object (the correct Microsoft account) to the app. With assignment required, other accounts (including a second M365 account owned by the same person) are not granted access unless explicitly assigned.
3. Use tenant and user identifiers from the token in the app
   In a multitenant scenario, the app must validate the token claims at runtime:
   • If the app is registered as Accounts in any organizational directory (multitenant), it can receive tokens from many tenants.
   • In the app code, check the tid (tenant ID) claim and, if needed, the oid or sub (user ID) claim against an allowed list.
   • Deny access if the tid (and/or user ID) does not match the tenant and user that were invited and provisioned. This prevents a second M365 account (different tenant or different user object) from being accepted, even if the same person controls it.
4. Map users to tenants and store immutable identifiers
   For a multitenant solution, maintain a mapping of which user (by immutable ID) belongs to which tenant:
   • During sign-up or invitation, associate the user’s tenant and user ID with the application’s tenant record.
   • Store the tenant ID and user ID as the authoritative mapping.
   • On every sign-in, use the token’s tenant and user identifiers to look up the allowed tenant/user combination and reject mismatches.
5. Use provisioning (optional but recommended)
   If the SaaS app supports provisioning (SCIM or similar), configure Microsoft Entra automatic provisioning:
   • Provision only the invited account to the application.
   • When access is removed in Entra (for that specific account), the app is updated automatically. This keeps the app’s internal user store aligned with the specific account that should have access.

By combining:

• Entra-only SSO (no local sign-in),
• “User assignment required” on the Enterprise app,
• Token-based checks on tid/user ID in the app code,
• Optional automatic provisioning,

the application dynamically ensures that only the originally invited Microsoft account can access it, and any other M365 account owned by the same person is denied.

---

References:

• Manage access to an application
• Integrating applications with Microsoft Entra ID and establishing a baseline of reviewed access
• Identity and account types for single- and multitenant apps
• Architectural considerations for identity in a multitenant solution
• Prepare for an access review of users' access to an application