Apply Geo fencing on Azure AD B2C

Question

Apply Geo fencing on Azure AD B2C

20759943 20

All login flows on Azure AD B2C must be routed to the region where the request was originated.

For e.g.: All US requests for login should be routed to the B2C server in US region.

Is this possible?
How to achieve?

0 comments

Answer accepted by question author

1 additional answer

Your answer

Answer 1

VEMULA SRISAI 11,380 Microsoft External Staff Moderator

Hello 20759943,

No, Azure AD B2C does not support geo‑based routing of sign‑in requests within a single B2C tenant. Azure AD B2C is a globally distributed service, and you cannot force requests from a specific country (for example, the US) to authenticate against a specific regional B2C endpoint automatically.

https://learn.microsoft.com/en-us/azure/active-directory-b2c/b2c-global-identity-solutions

If you require geo‑fencing or regional authentication, Microsoft’s supported approach is to deploy multiple Azure AD B2C tenants (one per region) and route users before they reach B2C.

How this is achieved (supported design):

Create one Azure AD B2C tenant per region (e.g., US, EU, APAC).
Use Azure Front Door / Traffic Manager / DNS to route users to the correct regional application endpoint based on geography.
Each regional application is configured to authenticate against its local B2C tenant.
Optionally, maintain a global lookup store to map users to their home region and support travelers or cross‑region sign‑ins using custom policies and APIs.

https://learn.microsoft.com/en-us/azure/active-directory-b2c/b2c-global-identity-region-based-design

Important: All geo‑routing happens outside Azure AD B2C. B2C itself cannot redirect or select a region based on the user’s location.

20759943 20 Reputation points

2026-03-06T12:35:50.71+00:00

thanks for the response. I understand that a single B2C tenant cannot support geo-based routing. But I would like to understand the options to achieve of which one is Regional tenant orchestration, where in application decides to route to the right B2C tenant by region and other one is Funnel tenant orchestration. As I was going through the article, I could not find how to redirect to the right regional tenant by making use of Policy engine. Can this be described a little bit more or could you please share a video link explaining this?
VEMULA SRISAI 11,380 Reputation points Microsoft External Staff Moderator

2026-03-10T14:33:30.8833333+00:00

20759943 Thanks for your question this is a common area of confusion, so let me clarify it clearly.

In Regional tenant orchestration, the application (or Azure Front Door / Traffic Manager / DNS) decides the user’s region and routes them to the appropriate regional Azure AD B2C tenant before sign‑in starts. In this model, the B2C policy engine is not involved in redirecting across tenants; it only runs inside the selected tenant to perform authentication.

In Funnel tenant orchestration, all sign‑in requests first land in a single global (funnel) B2C tenant. Here, the policy engine does not do geo‑ or IP‑based routing; instead, it orchestrates federation. Based on claims such as client ID, domain hint, or a lookup result, the funnel policy federates to the correct regional B2C tenant using OpenID Connect, and that regional tenant performs authentication.

This is why you don’t see “geo redirect” logic in policy XML geo decisions must happen outside B2C, or be passed in as claims; policies can only orchestrate federation after the request reaches a tenant.

Regional approach: https://learn.microsoft.com/en-us/azure/active-directory-b2c/b2c-global-identity-region-based-design

Funnel approach (with policy examples):https://learn.microsoft.com/en-us/azure/active-directory-b2c/b2c-global-identity-funnel-based-design

Funnel PoC:https://learn.microsoft.com/en-us/azure/active-directory-b2c/b2c-global-identity-proof-of-concept-funnel
VEMULA SRISAI 11,380 Reputation points Microsoft External Staff Moderator

2026-03-13T08:07:43.75+00:00

20759943 If the resolution was helpful, kindly take a moment to click on

and click on Yes for was this answer helpful. And, if you have any further query do let us know
20759943 20 Reputation points

2026-03-13T09:45:03.94+00:00

sorry, it took more time to respond. Now I understand the Funnel Tenant Orchestration. The setup is not a straight forward implementation rather we should use IEF (Identity Experience Framework) to update the policy and route to the corresponding B2C Tenant accordingly. I'll look at the POC you have shared and thanks for sharing. This explains it all for now.

Answer 2

Yes, geo-fencing style routing for Azure AD B2C sign-in is possible, but it is not done inside a single tenant. It is achieved by using multiple regional Azure AD B2C tenants and an architecture that routes users to the correct regional tenant based on their location or identifier.

There are two documented patterns:

Region-based approach (per-region tenants, apps point directly to them)
Funnel-based approach (one global “funnel” tenant that orchestrates to regional tenants)

1. Region-based approach

Concept:

Create one Azure AD B2C tenant per region (for example, NOAM, EMEA, APAC).
Applications are configured per region and send users directly to the regional tenant.
A global lookup table and APIs are used to support traveling users and prevent duplicate sign-up across regions.

How it works for sign-in:

DNS/traffic manager routes the user to the regional app endpoint (for example, myapp.fr → EMEA tenant, myapp.us → NOAM tenant).
The user signs in against the regional tenant.
For traveling users, the regional tenant:
- Looks up the user’s region in a global lookup table.
- If the account is in another region, performs a cross-tenant credential verification (for example, Microsoft Entra ROPC flow) against the home-region tenant.
- Optionally calls Microsoft Graph in the home-region tenant to read the user profile.

How it works for sign-up and password reset:

Sign-up:
- User signs up in the local regional tenant.
- The tenant writes the user profile locally and writes a username/email → region mapping into a global lookup table.
Password reset:
- Regional tenant validates email, looks up the user’s region, and either resets locally or via cross-tenant call.

Key building blocks:

Multiple Azure AD B2C tenants (one per region).
Custom policies in each tenant implementing:
- Sign-up journey with lookup to a user-region mapping table and write-back of mapping.
- Sign-in journey with region lookup and local or cross-tenant auth.
- Password reset journey with region lookup and local or cross-tenant password write.
Storage layer for the global lookup table (for example, Azure Table Storage) holding email/objectId/region.
External API layer used by custom policies to:
- Check if a user already exists in any region.
- Perform cross-tenant operations as needed.
DNS/Traffic Manager to route users to the correct regional application endpoint.

This model gives:

Data residency per region.
Optimized latency per region.
Ability to authenticate traveling users via cross-tenant flows.

2. Funnel-based approach

Concept:

All applications talk to a single “funnel” Azure AD B2C tenant.
The funnel tenant then orchestrates to regional tenants based on a global lookup (for example, email → region).

How it works:

Funnel tenant:
- Has federations configured to each regional Azure AD B2C tenant/policy combination.
- Uses a claim transformation (lookup) to map client_id or user identifier to a region.
- Enables the appropriate federation based on that mapping.
Regional tenants:
- Each has an app registration to establish federation with the funnel tenant.
Sign-in:
- Funnel tenant performs identifier-to-region lookup (via global lookup table or emulated via claim transformation).
- For traveling users, uses API-based authentication and Microsoft Graph calls to fetch the user profile from the correct regional tenant.
Sign-up:
- Writes the user’s region to the global lookup table.
Password reset:
- Uses identifier-to-region lookup and cross-tenant password reset via REST API.

Trade-offs:

Region-based:
- Apps must be configured per region and know which tenant to use.
- Optimized for cost and supports fine-grained Conditional Access.
Funnel-based:
- All apps use a single endpoint (funnel tenant), simplifying app configuration.
- Incurs double-token cost and an extra HTTP redirect.

Summary for the questions

Is this possible?
- Yes. Geo-based routing of login flows is supported by using multiple regional Azure AD B2C tenants with either a region-based or funnel-based global identity architecture.
How to achieve?
- Deploy one Azure AD B2C tenant per region where user data must reside.
- Implement either:
  - Region-based approach: apps are region-specific and send users directly to the regional tenant, using a global lookup table and cross-tenant flows for traveling users; or
  - Funnel-based approach: a single funnel tenant fronts all apps and routes to regional tenants based on identifier-to-region lookup.
- Use:
  - Custom policies in each tenant to implement sign-up, sign-in, and password reset journeys with region lookup and cross-tenant calls.
  - A storage-backed global lookup table (for example, Azure Table Storage) for email/ID → region mapping.
  - External APIs and Microsoft Graph for cross-tenant authentication, profile read, and password reset.
  - DNS/Traffic Manager or app-level routing to send users to the appropriate regional endpoint (region-based model) or to the funnel tenant (funnel-based model).

References:

Share via

Apply Geo fencing on Azure AD B2C

1 additional answer

1. Region-based approach

2. Funnel-based approach

Summary for the questions

Your answer