Opinions on Entra security architecture for SaaS

Question

Opinions on Entra security architecture for SaaS

Philip Hendry 110

I manage a SaaS application that comprises an asp.net core web api and React SPA frontend with authentication managed by a custom solution. I'm migrating that security system to Entra managed but would like opinions on the architecture I've chosen.

I've created an Entra External ID (CIAM) tenant to handle the following account types:

Local accounts: email/password sign-up
Social accounts: Google
Non-Entra B2B SSO registered as SAML or OIDC custom identity providers.

Initially I had hoped to federate our own Entra Workforce tenants so our employees can log in but neither SAML nor OIDC federation is possible Entra-to-Entra so instead I've configured our workforce tenant as another issuer of tokens my API validates. In addition I've created an app registration in this tenant that is a multi-tenant application and therefore other external Entra tenants, once white-listed, can sign in.

This split between workforce and CIAM tenants does complicate the code slightly but also seems to have overcome all the issues I faced with trying to define it all in just the CIAM tenant.

I've also turned on the Native Authentication API so I could build my own login page since, even though the Microsoft pages can be branded, the user journey was awkward to control - especially when needing to decide between two different MSAL instances to use (one for CIAM and the other for workforce.)

Does this sounds like a reasonable architecture? Has anyone been using something similar to deliver a SaaS to the range of account types I've listed above?

Shubham Sharma 15,695 Reputation points Microsoft External Staff Moderator

2026-04-06T15:03:21.0033333+00:00
Hello Philip Hendry

Thank you for reaching out to Microsoft Q&A.

This architecture makes sense—and it’s a pattern we see often when teams want a clear separation between customer identities (CIAM) and their internal workforce. A few thoughts:

Splitting CIAM vs. Workforce

It gives you strong isolation, different user stores, policies etc.

The downside is two identity endpoints and two MSAL configs in your front end.

Single-Tenant B2C with Azure AD as IDP

Instead of standing up a separate “workforce” tenant, you can federate your corporate Azure AD as an OIDC/SAML identity provider in your External ID (Azure AD B2C) tenant.

You’d then have one B2C app registration and a single MSAL instance, with user flows (or custom policies) directing enterprise logins to your work directory and consumer logins to local/social.

Multi-Tenant Entra Workforce App

Your multi-tenant app registration is a good way to onboard other organizations’ Entra tenants. You can also wire that into B2C as an external IDP so everything still lives in one B2C tenant.

Custom UI vs. Built-In Pages

Calling the Native Auth API for a fully custom-branded experience is totally valid, especially if you need fine-grained control over step-by-step journeys.

If you can live with less UI customization, the built-in B2C pages + page layouts might simplify maintenance.

Bottom line: your split-tenant approach will absolutely work—and you’ve solved the federation limitation nicely by treating the workforce tenant as an issuer. If you’re open to consolidating, look at Azure AD B2C’s built-in support for Azure AD identity providers (via user flows or custom policies). That can reduce the number of tenants and MSAL instances you manage.

Let us know the above steps helps

Thanks

Reference docs

How to configure Microsoft Entra authentication for an existing cluster https://github.com/Azure/Service-Fabric-Troubleshooting-Guides/blob/master/Security/Configure%20Azure%20Active%20Directory%20Authentication%20for%20Existing%20Cluster.md

How to set up Microsoft Entra ID for client authentication https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-creation-via-arm#set-up-azure-active-directory-for-client-authentication

How to assign users to a role https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-creation-via-arm#assign-users-to-roles

Common questions and solutions for Microsoft Entra configuration https://github.com/Azure/Service-Fabric-Troubleshooting-Guides/blob/master/Security/README.md#aad-configuration

Service Fabric security concepts https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-security

Service Fabric security recommendations https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-security#security-recommendations

Service Fabric Security Best Practices https://docs.microsoft.com/azure/service-fabric/service-fabric-best-practices-security

Service Fabric Production environment checklist https://docs.microsoft.com/azure/service-fabric/service-fabric-production-readiness-checklist
Philip Hendry 110 Reputation points

2026-04-07T12:53:54.97+00:00

Thank you so much for taking the time to offer your opinions - they're gratefully received.

I had initially tried to use the CIAM tenant to federate our corporate workforce tenant but Entra-to-Entra OIDC federation is explicitly not supported and it took me a while to figure this out but SAML federation isn't supported either which is why I ultimately decided to validate workforce issued tokens (and in digging out the link to my question regarding SAML configuration it would appear you helped me out there too :). Whilst having two MSAL instances does make things a bit more complex, trusting tokens issued by our workforce tenant meant sign in worked immediately and with a better user experience.

In your response you mentioned Azure AD B2C but this isn't an option for me given it's now unavailable. On reflection, my initial question didn't make it absolutely clear but I'm using an Entra External ID external tenant for CIAM which doesn't appear to be as mature as B2C (yet, at least.)

I discovered the following whilst writing my response:

I was just hunting for a link to the document which highlighted Entra-to-Entra OIDC was not supported but then came across Add a Microsoft Entra ID tenant as an OpenID Connect identity provider and which appears to be newly added in the last few days! This is a frustrating discovery if indeed External ID now supports this feature! I'll have to give this a go and if it works I'll be very happy (with a hint of disappointment that I've spent so long trying to get there!)
Shubham Sharma 15,695 Reputation points Microsoft External Staff Moderator

2026-04-08T15:49:13.4766667+00:00
Philip Hendry

Thank you for your reply.

Why the original approach was reasonable

Microsoft Entra External ID (CIAM) did not support Entra‑to‑Entra OIDC federation

SAML federation was also not supported

Treating your workforce tenant as a separate token issuer and validating those tokens directly in your API was a pragmatic and well‑designed workaround

Although it introduced:

Two MSAL configurations

Slightly more complexity in the frontend it delivered:

Immediate sign‑in success

Better UX

Clear isolation between customer and workforce identities

This is a pattern Microsoft has seen used successfully when CIAM feature parity was still evolving.

Microsoft has very recently added support for using a Microsoft Entra ID tenant as an OpenID Connect identity provider in an Entra External ID tenant.

https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-custom-oidc-federation-customers

This capability enables exactly what you originally tried to do:

Federate a workforce Entra tenant into CIAM using OIDC

Centralize authentication into a single External ID tenant

Reduce the need for:

Multiple issuers

Multiple MSAL instances

Custom token validation logic

Given how new this feature is, it explains why earlier attempts failed and why the guidance at that time explicitly stated it was unsupported.

What this means for your architecture now

You have two valid options, depending on your priorities:

Option 1 – Keep your current architecture (still valid)

CIAM tenant for customers (local, social, external IdPs)

Workforce tenant treated as a trusted token issuer

Two MSAL instances

Explicit audience/issuer validation in the API

Stable, proven, good UX

More code and configuration to maintain

Option 2 – Consolidate using new OIDC federation support

CIAM External ID remains the single identity plane

Workforce tenant configured as an OIDC identity provider

One CIAM app registration

One MSAL configuration (even with Native Authentication)

Simpler long‑term model

Feature is new and may still have CIAM‑specific edge cases

Microsoft documentation currently recommends this approach for reducing tenant sprawl and identity complexity where possible.

https://learn.microsoft.com/en-us/entra/identity-platform/concept-native-authentication
Shubham Sharma 15,695 Reputation points Microsoft External Staff Moderator

2026-04-10T13:16:51.6966667+00:00

Philip Hendry

Following up to check if the resolution provided was helpful. Please let us know if you need any further assistance.
Philip Hendry 110 Reputation points

2026-04-10T14:38:00.6266667+00:00

Hi @Shubham Sharma ,

I think I'll stick to having two token issuers because the multitenant app registration means integration with external entra tenants is so seamless. Please correct me if I'm wrong, but wouldn't only having the CIAM tenant mean I'd need custom OIDC identity provider configuration for each external Entra tenant I'd want to federate?

And that leads me on to another question I have - if I federate an external business identity provider (say acme.auth0.com) with my CIAM tenant using OIDC configuration then this works fine if I assign the IdP to a sign up user flow then click the "Sign in with acme.auth0.com" button. However, I don't want a button for each IdP I register (given they're being registered for B2B SSO) so I've been "playing" with Graph API and trying to auto-provision a user in the CIAM tenant during sign in but haven't quite succeeded yet. I know there are APIs such as SCIM for provisioning users but I was hoping to be able to use the functionality in Entra that's already there. Any ideas how to achieve this as it seems like the only part of my configuration that I can't get working. Is Graph API my best chance?

Kind regards,

Phil
Shubham Sharma 15,695 Reputation points Microsoft External Staff Moderator

2026-04-15T15:55:30.4866667+00:00

Philip Hendry

Following up to check if the resolution provided was helpful. Please let us know if you need any further assistance.
Philip Hendry 110 Reputation points

2026-04-15T17:32:37.98+00:00
Hi @Shubham Sharma,

Apologies, I saw an email notification for your reply just now but not one for thr previous!

This is exactly what I needed to hear - and I haven't been beating my head against a brick wall for no reason!!

Everything you said makes sense and aligns with my experience so I think my final architecture will be:

Our Workforce tenant is an issuer of tokens allowing our employees to sign in.

A multi-tenant app registration in the workforce tenant will allow external Entra users to sign in with their accounts with their tenants white-listed in our application.

A CIAM tenant provides sign in and sign up for local accounts.

The CIAM also allows for social sign in/up for Google.

And this is where it may get controversial, but for SAML/OIDC federations I'll consider creating an app registration for each one which will have it's own sign in and sign up user flow. I don't think we'll have a huge number of these types of federations so it shouldn't be too arduous and it leans on the user flow that just works.

And just a side not to all of this. I've just been experimenting with a Auth0 identify provider configure as a custom identity provider using SAML which isn't in any user flow. Logging in initially fails since the user doesn't exist in the CIAM tenant and, more importantly, the login_hint provided to MSAL.js routed to the Auth0 login correctly. This is where it gets interesting and my contradict something you said above, but using the Graph Explorer I posts to https://graph.microsoft.com/v1.0/invitations the following:

{ "invitedUserEmailAddress": "******@mytenantname.uk.auth0.com", "sendInvitationMessage": false, "inviteRedirectUrl": "http://localhost:30662" }

Then when I signed in again the consent prompt appears and once approved I'm signed in! And the user that was created by the invitiation now has the invitiation marked as accepts and their identities list the federated Auth0 just as it would have been if I'd gone through a user flow sign up.

Is this just a fluke or is this working in much the same way the user flow is and it's not likely to break? If so, then for SAML custom identity providers at least (since I have a different issue with OIDC ones), I may get away with the unified approach.

For my question here your answer on the 13th is definitely the one to accept - would you post that as an answer and I'll accept it.

And thank you again for your support - it's really appreciated!
Shubham Sharma 15,695 Reputation points Microsoft External Staff Moderator

2026-04-15T17:40:02.2566667+00:00

Hello Philip Hendry

Thank you for your reply and your valuable feedback.

I have posted an answer, please take a moment to accept the answer and upvote it 👍.

Thank you.

Answer accepted by question author

0 additional answers

Your answer

Philip Hendry 110 Reputation points

2026-04-07T12:53:54.97+00:00

Thank you so much for taking the time to offer your opinions - they're gratefully received.

I had initially tried to use the CIAM tenant to federate our corporate workforce tenant but Entra-to-Entra OIDC federation is explicitly not supported and it took me a while to figure this out but SAML federation isn't supported either which is why I ultimately decided to validate workforce issued tokens (and in digging out the link to my question regarding SAML configuration it would appear you helped me out there too :). Whilst having two MSAL instances does make things a bit more complex, trusting tokens issued by our workforce tenant meant sign in worked immediately and with a better user experience.

In your response you mentioned Azure AD B2C but this isn't an option for me given it's now unavailable. On reflection, my initial question didn't make it absolutely clear but I'm using an Entra External ID external tenant for CIAM which doesn't appear to be as mature as B2C (yet, at least.)

I discovered the following whilst writing my response:

I was just hunting for a link to the document which highlighted Entra-to-Entra OIDC was not supported but then came across Add a Microsoft Entra ID tenant as an OpenID Connect identity provider and which appears to be newly added in the last few days! This is a frustrating discovery if indeed External ID now supports this feature! I'll have to give this a go and if it works I'll be very happy (with a hint of disappointment that I've spent so long trying to get there!)
Shubham Sharma 15,695 Reputation points Microsoft External Staff Moderator

2026-04-10T13:16:51.6966667+00:00

Philip Hendry

Following up to check if the resolution provided was helpful. Please let us know if you need any further assistance.
Philip Hendry 110 Reputation points

2026-04-10T14:38:00.6266667+00:00

Hi @Shubham Sharma ,

I think I'll stick to having two token issuers because the multitenant app registration means integration with external entra tenants is so seamless. Please correct me if I'm wrong, but wouldn't only having the CIAM tenant mean I'd need custom OIDC identity provider configuration for each external Entra tenant I'd want to federate?

And that leads me on to another question I have - if I federate an external business identity provider (say acme.auth0.com) with my CIAM tenant using OIDC configuration then this works fine if I assign the IdP to a sign up user flow then click the "Sign in with acme.auth0.com" button. However, I don't want a button for each IdP I register (given they're being registered for B2B SSO) so I've been "playing" with Graph API and trying to auto-provision a user in the CIAM tenant during sign in but haven't quite succeeded yet. I know there are APIs such as SCIM for provisioning users but I was hoping to be able to use the functionality in Entra that's already there. Any ideas how to achieve this as it seems like the only part of my configuration that I can't get working. Is Graph API my best chance?

Kind regards,

Phil
Shubham Sharma 15,695 Reputation points Microsoft External Staff Moderator

2026-04-15T15:55:30.4866667+00:00

Philip Hendry

Following up to check if the resolution provided was helpful. Please let us know if you need any further assistance.
Shubham Sharma 15,695 Reputation points Microsoft External Staff Moderator

2026-04-15T17:40:02.2566667+00:00

Hello Philip Hendry

Thank you for your reply and your valuable feedback.

I have posted an answer, please take a moment to accept the answer and upvote it 👍.

Thank you.

Answer 1

Hello Philip Hendry

Thank you for the reply.

Yes- If you collapse everything into the CIAM tenant and rely only on OIDC‑federated external IdPs, then:

Each external Entra tenant would need its own OIDC identity provider configuration
That means:
- Separate metadata endpoints
- Separate client registrations
- Separate issuer validation paths
This does not scale well for B2B SaaS onboarding

For your reference: https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-custom-oidc-federation-customers

By contrast, the current model using:

A multi-tenant workforce app registration
Allowing external Entra tenants to consent
Trusting those tenants as token issuers directly in your API

is still the most scalable solution for onboarding many enterprise customers quickly.

That pattern exists explicitly to avoid the “custom IdP per tenant” problem.

I don’t want a button per IdP — what is actually supported?

This is the real pain point in Entra External ID today, and your experience matches the platform limitations precisely.

What Entra External ID supports out-of-the-box

Identity providers must be:

Explicitly registered

Explicitly enabled on a user flow

Each IdP appears as a UI option/button in the user flow

There is no first-class “home realm discovery” (HRD) like classic ADFS

“Silent discovery of the correct IdP based on email domain”

Not supported today in External ID user flows

3. Can Entra auto-provision users from federated IdPs?

Yes — but only during sign-in, not via Graph

When a user signs in through a federated OIDC or SAML IdP, Entra External ID will:

Automatically create a local representation of that user

Apply claims mapping you defined

Link the external identity to the user object

This is not SCIM and not Graph-driven provisioning — it’s sign-in‑time provisioning

You do NOT need Graph API just to create the user

4. Why the “no button per IdP” scenario is so hard

Below are the options: -

Option A – Domain-based routing in your own UI (most common)

Since you are already using Native Authentication / custom UI, the cleanest approach is:

User enters email

You inspect the domain (@acme.com)

You decide:

Workforce tenant

Multi-tenant Entra app

External OIDC IdP

You initiate the correct auth flow directly

Without exposing multiple buttons

This is not built into Entra, but fully supported when you own the UX

This avoids:

Buttons for each IdP

Graph hacks

SCIM complexity

Option B – One multi-tenant Entra path for all enterprises

Many SaaS platforms simplify by saying:

“All enterprise customers use Entra ID. Non-Entra customers use local or social.”

This lets you:

Keep one enterprise sign-in button

Let Entra handle tenant selection & consent

Avoid custom IdPs entirely

Not always acceptable — but massively simpler.

Option C – Graph API / SCIM before sign-in

This is not recommended for your scenario because:

Graph cannot pre‑provision users before authentication context exists

SCIM is for lifecycle management, not auth-time discovery

You still wouldn’t know which IdP to use until the user authenticates

Key limitation to be aware of with Native Authentication

One important call‑out from the docs:

Native authentication does NOT support federated identity providers yet

(Enterprise or social sign-in still requires browser-based auth)

https://learn.microsoft.com/en-us/entra/identity-platform/concept-native-authentication

So:

Native Auth - for local accounts

Browser redirect - still required for enterprise / OIDC IdPs

This doesn’t invalidate the architecture — but it does mean your routing logic must handle two paths cleanly.

Share via

Opinions on Entra security architecture for SaaS

0 additional answers

Your answer