Microsoft Entra External Identities: B2B and B2C

Microsoft Entra External Identities is a suite of identity and access management (IAM) solutions designed for external user scenarios. It includes two primary capabilities: Microsoft Entra B2B (business-to-business) and Microsoft Entra B2C (business-to-consumer). Both allow external users to access your applications and resources, but they differ fundamentally in architecture, trust model, and management scope.

B2B collaboration relies on federation and invitation redemption. When you invite an external user, Microsoft Entra sends an email with a link. The user clicks the link and authenticates at their home identity provider. After successful authentication, Microsoft Entra creates a *guest user object* in your tenant with UserType = "Guest". This object contains minimal information (display name, email, home tenant ID). The user does not have a password in your tenant—authentication is always delegated to their home IdP.

Redemption process: 1. Inviter sends invitation via Azure portal, PowerShell, or Microsoft Graph. 2. User receives email with redemption link (or clicks a direct link to an app). 3. User authenticates at their home IdP (e.g., contoso.com). 4. Microsoft Entra validates the token and creates/updates the guest user object. 5. User is redirected to the target application with an access token.

Token issuance: When the guest user accesses a resource, Microsoft Entra issues an access token that includes claims from both the home tenant (e.g., object ID) and the resource tenant (e.g., tenant ID). The resource application uses this token to authorize access. The token lifetime is configurable (default: 60–90 minutes for access tokens, up to 1 day for refresh tokens).

Cross-tenant access settings: You can configure inbound and outbound trust settings to control which external tenants can access your resources and which of your users can access external tenants. These settings include: - B2B direct connect: Allows Teams Connect shared channels without explicit invitation. - Trust settings: You can trust MFA and device claims from the home tenant. - Automatic redemption: Users can skip the initial consent prompt if trust is established.

B2C is a separate Azure service (not a feature of your corporate tenant). You create a B2C tenant (e.g., contoso.b2clogin.com) that acts as an identity provider for your customers. It stores user profiles in its own directory, separate from your corporate tenant. B2C uses custom policies (Identity Experience Framework) or user flows to define the sign-up/sign-in experience.

User flow example (sign-up/sign-in): 1. User navigates to your application and clicks "Sign up / Sign in". 2. Application redirects to the B2C tenant endpoint (e.g., https://contoso.b2clogin.com/contoso.onmicrosoft.com/oauth2/v2.0/authorize...). 3. B2C presents a page where the user can choose an identity provider (Google, Facebook, local account). 4. If local account, user enters email and password; B2C validates against its directory. 5. If social IdP, user authenticates at that provider; B2C receives an ID token. 6. B2C creates or updates the user profile in its directory (attributes like name, city, etc.). 7. B2C issues an ID token and access token to the application.

Token issuance: B2C issues JSON Web Tokens (JWT) signed by the B2C tenant. The token includes claims defined in the policy (e.g., objectId, email, custom attributes). Token lifetimes are configurable via policy (default: access token 1 hour, ID token 1 hour, refresh token up to 90 days if sliding window enabled).

Custom policies: For advanced scenarios, B2C allows XML-based policies that define the exact claims, API connectors, and multi-step journeys. For example, you can collect additional user attributes during sign-up, validate them against an external system, or require MFA via SMS or email.

B2B: - Guest user object: Created in your tenant; UserType = "Guest"; no password. - Invitation link: Expires after 48 hours by default (configurable via PowerShell Set-MgUser). - Cross-tenant access settings: Default: no trust; all external tenants blocked unless explicitly allowed. - B2B direct connect: Requires setting up cross-tenant trust; supports Teams Connect shared channels. - Automatic redemption: If enabled, users skip the consent screen. - MFA trust: If you trust MFA from the home tenant, guest users don't need to re-register MFA in your tenant.

B2C: - B2C tenant: Separate resource; must be created in the same region as your application. - User flows: Predefined (sign-up/sign-in, profile editing, password reset) or custom (Identity Experience Framework). - Identity providers: Local accounts (email/password), social (Google, Facebook, Apple, Microsoft, GitHub, etc.), SAML/WS-Fed IdPs. - Token lifetimes: Access token default 1 hour; refresh token up to 90 days (sliding window). - Session management: Configurable session lifetimes (default: 24 hours for web app, 90 days for mobile). - Custom attributes: Up to 100 custom attributes per B2C tenant (extend user schema).

B2B – Invite a guest user via PowerShell:

New-MgInvitation -InvitedUserEmailAddress "user@partner.com" -InviteRedirectUrl "https://myapp.contoso.com" -SendInvitationMessage:$true

B2B – List guest users:

Get-MgUser -Filter "userType eq 'Guest'"

B2C – Create a user flow via Azure CLI:

az rest --method post --uri "https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.AzureActiveDirectory/b2cDirectories/{b2c-tenant}/policies?api-version=2020-05-01-preview" --body @policy.json

B2C – Test sign-in: Use the "Run user flow" option in Azure portal to simulate authentication.

A manufacturing company, Contoso, needs to share project documents and applications with its supply chain partners. Contoso uses Microsoft 365 and has a Microsoft Entra tenant. Partners have their own Microsoft Entra tenants (e.g., Fabrikam). Contoso wants to grant Fabrikam employees access to a SharePoint Online site and a custom ERP app without managing their accounts.

Solution: Contoso uses Microsoft Entra B2B to invite Fabrikam users as guests. Contoso configures cross-tenant access settings to trust Fabrikam's MFA and device compliance claims. This way, Fabrikam employees use their own corporate credentials and MFA; Contoso does not need to issue separate tokens or enforce its own MFA. The guest users are added to a security group that grants access to the SharePoint site and the ERP app via app roles.

Common issues: If cross-tenant trust is not configured, guests are prompted to accept permissions each time. If the invitation link expires (48 hours), the guest must request a new invitation. If the partner's domain is not verified, the invitation may be blocked. Performance is generally good, but token validation can add latency if the home tenant is geographically distant.

A retail company, Northwind, builds a customer loyalty application. Customers can sign up using their Google or Facebook accounts or create a local account with email and password. Northwind needs to collect custom attributes (e.g., loyalty tier, birthday) and enforce MFA for high-value transactions.

Solution: Northwind creates a B2C tenant and configures user flows for sign-up/sign-in and profile editing. They integrate Google and Facebook as social identity providers. For MFA, they enable SMS or email one-time passcode in the user flow. They use custom policies to collect additional attributes during sign-up and store them in the B2C directory. The application uses the B2C tokens to authorize access to APIs.

Common issues: If the B2C tenant is in a different region than the application, latency increases. If custom policies are misconfigured, the sign-up flow may break. Token size can become large if many custom claims are added, potentially exceeding header size limits. B2C pricing is based on monthly active users (MAUs); high-traffic apps can incur significant costs.

A government agency provides an online portal for citizens to access tax records and apply for permits. Citizens must authenticate using their social security number (SSN) and a password. The agency needs to comply with identity assurance Level 2 (IAL2) requirements.

Solution: The agency uses B2C with custom policies to enforce identity verification. They integrate with a third-party identity proofing service via API connectors. During sign-up, the user enters their SSN and other PII; B2C calls the proofing service to validate the identity. After successful proofing, the account is created. B2C also enforces MFA via SMS. The agency uses Conditional Access (via Premium P2) to block access from suspicious IP addresses.

Common issues: Identity proofing adds latency; the sign-up flow may timeout if the API connector takes too long. B2C's default session timeout may be too short for long forms. Compliance with government standards requires careful configuration of token lifetimes and audit logging.