Edit

Build a global identity solution with funnel-based approach

  • Article

In this article, we describe the scenarios for funnel-based design approach. Before starting to design, it's recommended that you review the capabilities, and performance of both funnel and region-based design approach. This article will further help determine which design may fit best for your organization.

The designs account for:

  • Local Account sign up and sign in
  • Federated account sign up and sign in
  • Authenticating local accounts for users signing in from outside their registered region, supported by cross tenant API based authentication
  • Authenticating federated accounts for users signing in from outside their registered region, supported by cross tenant API based look up
  • Prevents sign up from multiple different regions
  • Applications in each region have a single endpoint to connect with

Local account sign-in use cases

The following use cases are typical in a global Azure AD B2C environment. The local account use cases also cover accounts where the user travels. We provide a diagram and workflow steps for each use case.

Local user sign-up

This use case demonstrates how a user from their home country/region performs a sign-up with an Azure AD B2C Local Account.

Screenshot shows the Local user sign-up flow.

  1. A user from Europe, Middle East, and Africa (EMEA) attempts to sign up at myapp.fr. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the Global Funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on defined criteria using OpenId federation. This can be a lookup based on Application clientId.

  3. The user attempts to sign up. The sign-up process checks the global lookup table to determine if the user exists in any of the regional Azure AD B2C tenants.

  4. The user isn't found in the global lookup table. The user's account is written into Azure AD B2C, and a record is created into the global lookup table to track the region in which the user signed-up.

  5. The regional tenant issues a token back to the funnel tenant.

  6. The funnel tenant issues a token to the application.

Existing local user attempts sign up

This use case demonstrates how a user re-registering the same email from their own country/region, or a different region, is blocked.

Screenshot shows the existing account sign-up flow.

  1. A user from EMEA attempts to sign up at myapp.fr. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the Global Funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on Application clientId.

  3. The user attempts to sign up. The sign-up process checks the global lookup table to determine if the user exists in any of the regional Azure AD B2C tenants.

  4. The user's email is found in the global lookup table, indicating the user has registered this email in the solution at some prior point in time.

  5. The user is presented with an error, indicating their account exists.

Local user sign-in

This use case demonstrates how a user from their home country/region performs a sign-in with an Azure AD B2C local account.

Screenshot shows the local user sign-in flow.

  1. A user from EMEA attempts to sign in at myapp.fr. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the global funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on application clientId.

  3. The user enters their credentials at the regional tenant.

  4. The regional tenant issues a token back to the funnel tenant.

  5. The funnel tenant issues a token to the application.

Traveling user sign-in

This use case demonstrates how a user can travel across regions and maintain their user profile and credentials stored in their regional tenant respective to their sign-up.

Screenshot shows the traveling user sign-in flow.

  1. A user from North America (NOAM) attempts to sign in at myapp.fr while they are on holiday in France. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the global funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on Application clientId.

  3. The user enters their credentials at the regional tenant.

  4. The regional tenant performs a lookup into the global lookup table, since the user's email wasn't found in the EMEA Azure AD B2C directory.

  5. The user's email is located to have been signed up in NOAM Azure AD B2C tenant.

  6. The EMEA Azure AD B2C tenant performs a Microsoft Entra ROPC flow against the NOAM Azure AD B2C tenant to verify credentials.

    Note

    This call will also fetch a token for the user to perform a Graph API call. The EMEA Azure AD B2C tenant performs a Graph API call to the NOAM Azure AD B2C tenant to fetch the user's profile. This call is authenticated by the access token for Graph API acquired in the last step.

  7. The regional tenant issues a token back to the funnel tenant.

  8. The funnel tenant issues a token to the application.

Local user forgot password

This use case demonstrates how a user can reset their password when they are within their home country/region.

Screenshot shows the local user forgot password flow.

  1. A user from EMEA attempts to sign in at myapp.fr. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the global funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on application clientId.

  3. The user arrives at the EMEA Azure AD B2C tenant and selects forgot password. The user enters and verifies their email.

  4. Email lookup is performed to determine which regional tenant the user exists in.

  5. The user provides a new password.

  6. The new password is written into the EMEA Azure AD B2C tenant.

  7. The regional tenant issues a token back to the funnel tenant.

  8. The funnel tenant issues a token to the application.

Traveling user forgot password

This use case demonstrates how a user can reset their password when they're traveling away from the region in which they registered their account.

Screenshot shows the traveling user forgot password flow.

  1. A user from NOAM attempts to sign in at myapp.fr since they are on holiday in France. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the global funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on application clientId.

  3. The user arrives at the EMEA Azure AD B2C tenant and selects forgot password. The user enters and verifies their email.

  4. Email lookup is performed to determine which regional tenant the user exists in.

  5. The email is found to exist in the NOAM Azure AD B2C tenant. The user provides a new password.

  6. The new password is written into the NOAM Azure AD B2C tenant through a Graph API call.

  7. The regional tenant issues a token back to the funnel tenant.

  8. The funnel tenant issues a token to the application.

Local user password change

This use case demonstrates how a user can change their password after they've logged into the region in which they registered their account.

Screenshot shows the local user password change flow.

  1. A user from EMEA attempts selects change password after logging into myapp.fr.

  2. The user reaches the global funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on application clientId.

  3. The user arrives at the EMEA Azure AD B2C tenant, and the Single-Sign On (SSO) cookie set allows the user to change their password immediately.

  4. New password is written to the users account in the EMEA Azure AD B2C tenant.

  5. The regional tenant issues a token back to the funnel tenant.

  6. The funnel tenant issues a token to the application.

Traveling user password change

This use case demonstrates how a user can change their password after they've logged in, away from the region in which they registered their account.

Screenshot shows the flow for traveling user password change.

  1. A user from NOAM attempts change password after logging into myapp.fr.

  2. The user reaches the global funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on application clientId.

  3. The user arrives at the EMEA Azure AD B2C tenant, and the SSO cookie set allows the user to change their password immediately.

  4. The user's email is found to be in the NOAM tenant after checking the global lookup table.

  5. The new password is written to the users account in the NOAM Azure AD B2C tenant by MS Graph API call.

  6. The regional tenant issues a token back to the funnel tenant.

  7. The funnel tenant issues a token to the application.

Federated Identity Provider authentications

The following use cases show examples of using federated identities to sign up or sign in as an Azure AD B2C client.

Local federated ID sign-up

This use case demonstrates how a user can sign up to the service from their local region using a federated ID.

Screenshot shows the flow for federated ID sign-up.

  1. A user from EMEA attempts to sign up at myapp.fr. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the global funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on application clientId.

  3. The user selects to sign in with a federated Identity Provider (IdP).

  4. Perform a lookup into the global lookup table.

    • If account linking is in scope: Proceed if the federated IdP identifier nor the email that came back from the federated IdP doesn't exist in the lookup table.

    • If account linking is not in scope: Proceed if the federated IdP identifier that came back from the federated IdP doesn't exist in the lookup table.

  5. Write the users account to the EMEA Azure AD B2C tenant.

  6. The regional tenant issues a token back to the funnel tenant.

  7. The funnel tenant issues a token to the application.

Local federated user sign-in

This use case demonstrates how a user from their local region signs into the service using a federated ID.

Screenshot shows the flow for local federated user sign-in.

  1. A user from EMEA attempts to sign in at myapp.fr. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the global funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on Application clientId.

  3. The user selects to sign in with a federated identity provider.

  4. Perform a lookup into the global lookup table and confirm the user's federated ID is registered in EMEA.

  5. The regional tenant issues a token back to the funnel tenant.

  6. The funnel tenant issues a token to the application.

Traveling federated user sign-in

This use case demonstrates how a user can sign into their account with a federated IdP, whilst located away from the region in which they signed up in.

Screenshot shows the flow for traveling federated user sign-in.

  1. A user from NOAM attempts to sign in at myapp.fr. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the global funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on Application clientId.

  3. The user selects to sign in with a federated identity provider.

    Note

    Use the same App Id from the App Registration at the Social IdP across all Azure AD B2C regional tenants. This ensures that the ID coming back from the Social IdP is always the same.

  4. Perform a lookup into the global lookup table and determine the user's federated ID is registered in NOAM.

  5. Read the account data from the NOAM Azure AD B2C tenant using MS Graph API.

  6. The regional tenant issues a token back to the funnel tenant.

  7. The funnel tenant issues a token to the application.

Account linking with matching criteria

This use case demonstrates how users are able to perform account linking when matching criteria is satisfied. The matching criteria is typically the users email address. When the matching criteria of a sign in from a new identity provider has the same value for an existing account in Azure AD B2C, the account linking process can begin.

Screenshot shows the flow to merge a federated account.

  1. A user from EMEA attempts to sign in at myapp.fr. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the global funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on Application clientId.

  3. The user selects to sign in with a federated identity provider/social IdP.

  4. A lookup is performed into the global lookup table for the ID returned from the federated IdP.

  5. Where the ID doesn't exist, but the email from the federated IdP does exist in EMEA Azure AD B2C – this is an account linking use case.

  6. Read the user from the directory and determine which authentication methods are enabled on the account. Present a screen for the user to sign in with an existing authentication method on this account.

  7. Once the user proves they own the account in Azure AD B2C, add the new social ID to the existing account, and add the social ID to the account in the global lookup table.

  8. The regional tenant issues a token back to the funnel tenant.

  9. The funnel tenant issues a token to the application.

Traveling user account linking with matching criteria

This use case demonstrates how nonlocal users are able to perform account linking when matching criteria is satisfied. The matching criteria is typically the users email address. When the matching criteria of a sign in from a new identity provider has the same value for an existing account in Azure AD B2C, the account linking process can begin.

Screenshot shows the flow to merge traveling federated user.

  1. A user from NOAM attempts to sign in at myapp.fr. If the user isn't being sent to their local application instance, the traffic manager enforces a redirect.

  2. The user reaches the Global Funnel Azure AD B2C tenant. This tenant is configured to redirect to a regional Azure AD B2C tenant based on some criteria using OpenId federation. This can be a lookup based on Application clientId.

  3. The user selects to sign in with a federated identity provider/social IdP.

  4. A lookup is performed into the global lookup table for the ID returned from the federated IdP.

  5. Where the ID doesn't exist, and the email from the federated IdP exists in another region - this is a traveling user account linking use case.

  6. Create an id_token_hint link asserting the users currently collected claims. Bootstrap a journey into the NOAM Azure AD B2C tenant using federation. The user proves that they own the account via the NOAM Azure AD B2C tenant.

    Note

    This method is used to re-use existing account linking logic in the home tenant and reduce external API calls to manipulate the identities collection. A custom policy sample which utilizes id_token_hint can be found here.

  7. Once the user proves they own the account in Azure AD B2C, add the new social ID to the existing account by making a Graph API call to the NOAM Azure AD B2C tenant. Add the social ID to the account in the global lookup table.

  8. The regional tenant issues a token back to the funnel tenant.

  9. The funnel tenant issues a token to the application.

Next steps