This chapter covers Microsoft Entra External Identities, specifically the B2B (business-to-business) and B2C (business-to-customer) collaboration models. For the AZ-305 exam, this topic appears in Domain 1.1 (Design Identity Governance) and typically accounts for 10-15% of questions related to identity. Understanding the architectural differences, security boundaries, and appropriate use cases for B2B versus B2C is critical for designing identity solutions that meet enterprise requirements for collaboration and customer-facing applications.
Jump to a section
Think of a company building with a security desk. For B2B collaboration, imagine the company issues a 'guest pass' to employees of partner organizations. The guest pass is pre-approved: the partner's HR department vets their own employees, and the company's security desk trusts that vetting. When a partner employee arrives, they show their corporate ID (their home tenant credentials), and the security desk looks up the guest list (the B2B invitation). No new badge is created; they just sign in with their usual ID and get access to specific floors (resources) based on their role. For B2C, imagine a public concert. Anyone with a valid ticket (any identity provider—Google, Facebook, email) can enter. The ticket is self-service: the user creates an account or logs in with a social identity. The concert venue (the application) doesn't know or care who the user is beyond the ticket. The venue uses a separate directory (Azure AD B2C tenant) to manage these identities, completely isolated from the employee directory. The key difference: B2B is about extending your existing corporate directory to trusted external collaborators using their own identities; B2C is about creating a new, isolated directory for customers who use any identity they choose. In B2B, the partner's identity is federated; in B2C, the identity is stored or federated in a dedicated tenant that never mixes with employee accounts.
What are Entra External Identities?
Microsoft Entra External Identities is a family of identity solutions that allow organizations to secure and manage external users—partners, customers, and citizens—who need access to your apps and resources. The two primary models are Azure AD B2B (Business-to-Business) and Azure AD B2C (Business-to-Customer). While both handle external identities, they serve fundamentally different scenarios and have distinct architectures.
Azure AD B2B Collaboration
Azure AD B2B collaboration enables you to invite external users (from other Azure AD tenants, Microsoft accounts, or social identity providers) into your Azure AD tenant as 'guest users'. These guests authenticate using their home identity provider—their own organization's Azure AD, a Microsoft account, or a social IDP like Google or Facebook. The key principle: B2B extends your existing tenant's policy and access management to external users without requiring them to create a new identity in your tenant.
How B2B Works Internally: 1. Invitation: A user in your tenant (the inviter) sends an invitation via the Azure portal, PowerShell, or Microsoft Graph. The invitation includes a redemption URL. 2. Redemption: The external user receives an email with the redemption link. Clicking it redirects them to sign in with their home identity provider. After successful authentication, Azure AD creates a guest user object in your tenant (UserType = Guest). 3. Access: The guest user is now represented in your tenant and can be assigned to apps, groups, and roles. When accessing resources, they authenticate against their home IdP, and Azure AD issues a token for your tenant's resources based on the guest user's attributes and permissions.
Key Components and Defaults:
- Guest User Object: Created with UserType = Guest. Has a UPN like user@domain.com#EXT#@yourtenant.onmicrosoft.com. The #EXT# indicates an external user.
- Invitation Expiration: By default, invitations expire after 30 days. Configurable via InvitationRedeemTimeToLive in the InvitationSettings.
- Redemption Timeout: After the invitation is sent, the user has 48 hours to redeem before the link becomes invalid (configurable).
- Cross-tenant Access Settings: In Azure AD, you can configure inbound and outbound trust settings per external tenant. For example, you can trust MFA claims from the home tenant or block specific tenants.
- Conditional Access: Guest users can be subject to Conditional Access policies, but policies that require device compliance may not work if the guest's device is not managed by your tenant.
Configuration Commands (PowerShell):
# Send invitation
New-MgInvitation -InvitedUserEmailAddress "user@partner.com" -InviteRedirectUrl "https://myapp.contoso.com" -SendInvitationMessage:$true
# Get guest user
Get-MgUser -Filter "UserType eq 'Guest'"
# Configure cross-tenant access settings
Update-MgPolicyCrossTenantAccessPolicy -Default -InboundTrust @{IsMfaAccepted=$true; IsCompliantDeviceAccepted=$true}Azure AD B2C (Business-to-Customer)
Azure AD B2C is a separate identity service for customer-facing applications. It uses a dedicated Azure AD B2C tenant, which is isolated from your organization's Azure AD tenant. B2C supports multiple identity providers (social like Google, Facebook; enterprise like Azure AD; local accounts with email/password) and provides customization for sign-up, sign-in, and profile management.
How B2C Works Internally: 1. User Journey: When a user accesses an application, they are redirected to the B2C tenant's sign-in/sign-up page. The B2C tenant uses a 'user flow' (e.g., B2C_1_signupsignin1) to define the steps: identity provider selection, attribute collection, token issuance. 2. Authentication: The user authenticates with their chosen IdP. For social IdPs, B2C uses OAuth 2.0 or OpenID Connect. For local accounts, B2C stores the identity in its own directory (the B2C tenant's directory). 3. Token Issuance: After successful authentication, B2C issues a token (JWT) to the application, which can be used to access your APIs and resources. The token is issued by the B2C tenant, not your corporate Azure AD. 4. User Attributes: B2C allows you to collect custom attributes during sign-up (e.g., loyalty number, date of birth). These are stored in the B2C directory.
Key Components and Defaults:
- B2C Tenant: A separate Azure AD tenant, created via the Azure portal. It cannot be used for employee access. The tenant name is like contosob2c.onmicrosoft.com.
- User Flows: Predefined or custom policies that define the authentication journey. They include: sign-up/sign-in, profile editing, password reset. Custom policies (Identity Experience Framework) allow complex scenarios.
- Identity Providers: Configurable per user flow. Common social IdPs: Google, Facebook, Microsoft Account. Enterprise IdPs: Azure AD, SAML/WS-Fed IdPs.
- Token Lifetime: Default access token lifetime is 1 hour, refresh token up to 90 days (sliding window). Configurable via token lifetime policies.
- Session Management: B2C supports single sign-on (SSO) across apps within the same B2C tenant. Session timeout defaults to 24 hours.
Configuration Example (Custom Policy):
<!-- RelyingParty section of a custom policy -->
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<UserJourneyBehaviors>
<SingleSignOn Scope="Tenant" KeepAliveInDays="7" />
</UserJourneyBehaviors>
</RelyingParty>Architectural Differences
Directory Isolation: B2B guest users reside in your existing Azure AD tenant, alongside employee accounts. B2C users reside in a separate, isolated B2C tenant. This is crucial for security and compliance—customer identities never mix with employee identities.
Authentication Authority: In B2B, authentication happens at the guest's home tenant; your tenant issues tokens based on trust. In B2C, authentication happens at the B2C tenant; your application trusts the B2C tenant's tokens.
User Management: B2B guest users are managed via your tenant's directory (Azure AD portal). B2C users are managed via the B2C tenant's portal or Graph API.
Scalability: B2C is designed for millions of users; B2B is designed for smaller numbers of partner users.
Compliance: B2C offers granular control over data residency and user consent (GDPR). B2B relies on the guest's home tenant for compliance.
Interaction with Related Technologies
Azure AD B2B integrates with Azure AD Conditional Access, Identity Protection (limited for guests), and Microsoft 365 services (e.g., SharePoint, Teams). Guests can be added to Teams as external users.
Azure AD B2C integrates with Azure AD for workforce identity as an identity provider (e.g., employees logging into customer portal with corporate credentials). It also integrates with Azure API Management, Azure Functions, and Logic Apps for custom policies.
Microsoft Graph: Both B2B and B2C can be managed via Graph API. B2C uses the beta endpoint for some operations.
Pricing Considerations
B2B: Free for basic features (up to 50,000 guest users per tenant). Premium P1 or P2 required for advanced features like Conditional Access for guests, cross-tenant sync, and identity governance.
B2C: Pay-as-you-go pricing based on monthly active users (MAU). First 50,000 MAU are free. Different tiers for premium features like custom domains, risk-based Conditional Access, and identity protection.
Exam-Relevant Defaults and Values
B2B Invitation Expiration: Default 30 days, configurable.
B2C Token Lifetime: Access token default 1 hour; refresh token up to 90 days.
B2C Session SSO: Default 24 hours (KeepAliveInDays=0).
B2C User Flows: Can be versioned (e.g., B2C_1_signupsignin1).
B2B Guest User UPN Format: user@domain.com#EXT#@yourtenant.onmicrosoft.com.
B2C Tenant Creation: Requires an Azure subscription; you cannot convert an existing Azure AD tenant to B2C.
Common Traps
Trap: Mixing B2B and B2C: The exam may ask which solution to use for external partners vs. customers. Remember: B2B for partners (they have their own identity), B2C for customers (they need a new identity).
Trap: Guest user permissions: Guests can be assigned roles but cannot be added to the tenant as members by default. They can be converted to members if needed.
Trap: B2C tenant as a replacement for Azure AD: B2C is not a general-purpose directory; it cannot be used for employee access or device management.
Trap: Conditional Access for guests: Not all Conditional Access controls work for guests (e.g., device compliance requires managed device).
Identify Collaboration Scenario
Determine if the external users are business partners (B2B) or individual customers (B2C). B2B partners typically have their own identity provider (e.g., another Azure AD tenant) and need access to internal resources like SharePoint, Teams, or line-of-business apps. B2C customers are individuals who sign up for a customer-facing application (e.g., a retail portal). This decision drives the entire identity architecture. The exam tests your ability to distinguish based on the user's identity source: if they have an existing corporate identity, B2B; if not, B2C.
Design Directory Isolation
For B2B, guest users are added to your existing Azure AD tenant. This means they appear in the same directory as employees, which can simplify access management but requires careful governance to avoid accidental exposure. For B2C, you create a separate Azure AD B2C tenant that is completely isolated from your corporate directory. No customer accounts ever appear in your employee directory. This isolation is crucial for security and compliance, especially in regulated industries. The exam may ask which design prevents customer identities from mixing with employees—answer: B2C.
Configure Authentication Flow
For B2B, you need to set up cross-tenant access settings to trust the guest's home tenant. This includes trusting MFA, device compliance, and hybrid Azure AD join claims. Invitations are sent via email or direct API. The user authenticates at their home tenant and receives a token for your tenant. For B2C, you configure user flows that define the sign-up/sign-in experience. You choose which identity providers (social, enterprise, local) are available. The user authenticates at the B2C tenant, which issues a token directly to your application. The exam expects you to know that B2B uses federation trust, while B2C uses direct authentication.
Implement Access Control
For B2B, you assign guest users to apps and groups just like employees. Conditional Access policies can be applied, but with limitations (e.g., device compliance may not work). You can also use entitlement management to automate guest access lifecycle. For B2C, access control is handled within the application—the B2C tenant only issues identity tokens. The application uses those tokens to authorize access to its own resources. B2C does not provide direct access to Azure resources like storage or VMs. The exam may test that B2C is for application-level identity, not infrastructure access.
Plan for Governance and Compliance
B2B guests can be reviewed using Azure AD access reviews to ensure they still need access. Guest accounts can be disabled or removed automatically after a period. For B2C, you must manage user consent for data collection, provide privacy notices, and allow users to delete their accounts (GDPR). B2C provides APIs for user management and audit logs. The exam may ask which solution supports access reviews (B2B) or which supports self-service account deletion (B2C). Additionally, B2C offers region-specific data residency options, which is important for compliance.
Enterprise Scenario 1: Partner Collaboration with B2B
A multinational corporation, Contoso, needs to give its supply chain partners access to a shared SharePoint site and a line-of-business application. The partners have their own Azure AD tenants. Contoso uses Azure AD B2B to invite partner users as guests. They configure cross-tenant access settings to trust the partners' MFA policies, so partners don't need to enroll in Contoso's MFA. Access reviews are scheduled quarterly to remove inactive guests. In production, Contoso manages 5,000 guest users across 50 partner tenants. Common issues include invitation emails being blocked by spam filters and guest users not receiving tokens due to misconfigured cross-tenant trust. To mitigate, Contoso uses direct redemption links and monitors sign-in logs. Performance is generally good, but token issuance can be delayed if the partner's IdP is slow. The key lesson: B2B works well when partners have managed identities and you need tight integration with your existing Azure AD policies.
Enterprise Scenario 2: Customer Portal with B2C
A retail company, Northwind Traders, wants to build a customer portal where users can sign up with social accounts (Google, Facebook) or email/password. They create an Azure AD B2C tenant named 'northwindb2c'. They configure a sign-up/sign-in user flow that collects first name, last name, and email. They customize the UI with their brand colors and logo. The portal application is configured to use the B2C endpoint for authentication. In production, Northwind handles 500,000 monthly active users. Scaling considerations include token signing key rotation and custom policy performance. Common pitfalls: users losing access because of expired refresh tokens, or social IdP outages causing sign-in failures. Northwind implements custom policies to add a 'forgot password' flow and to integrate with their loyalty program API. The B2C tenant is isolated from their corporate Azure AD, so employee accounts are never exposed. The main challenge is managing custom policies, which are XML-based and can be complex to debug.
Scenario 3: Hybrid B2B and B2C
A healthcare provider, Fabrikam Health, uses B2B for partner organizations (insurance companies, labs) and B2C for patients accessing a patient portal. They maintain two separate Azure AD tenants: one for employees and B2B guests, and one B2C tenant for patients. This ensures patient data never mixes with employee or partner data. They use Azure AD B2C's custom policies to integrate with their Electronic Health Record (EHR) system via API. They also use B2B cross-tenant access settings to allow partner organizations to access internal apps. The separation is critical for HIPAA compliance. The main challenge is managing two identity systems and ensuring consistent security policies. The exam may test the understanding that B2B and B2C can coexist for different user types.
AZ-305 Exam Focus: Entra External Identities B2B vs B2C
This topic is tested under objective 1.1 'Design identity governance' and also appears in 1.2 'Design authentication and authorization'. Expect 3-5 questions on the exam that require choosing between B2B, B2C, or other identity solutions.
Common Wrong Answers and Why Candidates Choose Them: 1. Choosing B2B for customer-facing apps: Candidates see 'external users' and think B2B, but B2B is for business partners who have their own identity. Customers typically don't have corporate identities, so B2C is correct. 2. Choosing B2C for partner access: Candidates mistake B2C's ability to support Azure AD as an IdP as a reason to use it for partners. However, B2C is not designed for partner access to internal resources; it's for customer-facing apps. 3. Thinking B2B and B2C are interchangeable: The exam tests that they serve different purposes and have different architectures. B2B extends your existing tenant; B2C uses a separate tenant. 4. Assuming B2C can replace Azure AD for employees: B2C cannot be used for employee access to Office 365, Azure management, or enterprise apps. It is strictly for customer identities.
Specific Numbers and Terms That Appear on the Exam: - #EXT#: The suffix in guest UPN. - UserType = Guest: The attribute that identifies a B2B guest. - Cross-tenant access settings: The feature to trust external IdPs. - MAU (Monthly Active Users): Pricing model for B2C. - User flows vs. custom policies: User flows are simpler; custom policies are more flexible. - Token lifetime defaults: Access token 1 hour, refresh token 90 days (B2C).
Edge Cases and Exceptions: - B2B with social identities: You can invite users with Microsoft accounts or social IdPs as guests, but they are still B2B (they appear as guests in your tenant). However, for customer scenarios, B2C is preferred. - B2C with enterprise IdPs: You can configure B2C to accept Azure AD or SAML IdPs, allowing employees to log into customer apps with corporate credentials. This is still B2C, not B2B. - Guest user conversion: You can change a guest's UserType to Member, but this is uncommon and not recommended for partners.
How to Eliminate Wrong Answers: - If the scenario mentions 'partners', 'vendors', 'suppliers' with existing identities, eliminate B2C. - If the scenario mentions 'customers', 'consumers', 'citizens' without existing corporate identities, eliminate B2B. - If the question asks about directory isolation, B2C provides isolation; B2B does not. - If the question asks about cost, B2B is free for basic guest users; B2C has MAU-based pricing. - If the question mentions access reviews, B2B supports them; B2C does not (though you can use Graph API to build custom reviews).
B2B is for business partners with existing identities; B2C is for customers without corporate identities.
B2B guest users reside in your Azure AD tenant (UserType = Guest); B2C users reside in a separate B2C tenant.
B2B invitations expire after 30 days by default; B2C token lifetime defaults: access token 1 hour, refresh token 90 days.
B2B supports cross-tenant access settings to trust MFA and device claims from partner tenants.
B2C supports social identity providers (Google, Facebook, Microsoft Account) and local accounts.
B2C cannot be used for employee access to Office 365 or Azure management.
B2B is free for basic guest user features; B2C pricing is based on monthly active users (MAU).
B2C user flows are simpler; custom policies (XML) allow complex scenarios.
Conditional Access policies for B2B guests can be limited (e.g., device compliance may not apply).
B2C provides data residency options for compliance (e.g., EU, US).
These come up on the exam all the time. Here's how to tell them apart.
Azure AD B2B
Extends existing Azure AD tenant
Users are guests in your directory
Designed for partner collaboration
Free for up to 50,000 guests (basic features)
Supports Conditional Access and access reviews
Azure AD B2C
Uses a separate, isolated B2C tenant
Users are stored in B2C directory only
Designed for customer-facing applications
Pay-as-you-go based on MAU
No Conditional Access or access reviews (custom policies available)
Mistake
Azure AD B2C is just a renamed version of Azure AD B2B.
Correct
They are fundamentally different services. B2B extends your existing Azure AD tenant to include external users as guests. B2C is a separate identity service with its own tenant, designed for customer-facing applications. They have different architectures, pricing, and management tools.
Mistake
You can use B2C to give customers access to Azure resources like VMs or storage.
Correct
B2C only provides authentication and token issuance for applications. It does not grant access to Azure infrastructure. To give customers access to Azure resources, you would need to use Azure AD B2B or custom token exchange mechanisms.
Mistake
B2B guest users are stored in a separate directory from employees.
Correct
B2B guest users are stored in the same Azure AD tenant as employees. They appear as user objects with UserType = Guest. This means they are subject to the same directory policies unless specifically scoped.
Mistake
B2C cannot be used with Azure AD as an identity provider.
Correct
B2C supports Azure AD as an identity provider. This allows employees of your organization to log into customer-facing apps using their corporate credentials, while still maintaining separation of directories.
Mistake
B2B invitations never expire.
Correct
By default, B2B invitations expire after 30 days if not redeemed. This is configurable in the invitation settings. The redemption link itself expires after 48 hours.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, technically you can invite any email address as a B2B guest, including social accounts like Gmail. However, this is not recommended for customer scenarios because B2B guests appear in your corporate directory, which can be a security and compliance risk. For customer-facing applications, use Azure AD B2C, which is designed for that purpose and provides isolation, customization, and scalability.
A B2B guest is a user object in your existing Azure AD tenant with UserType = Guest. They share the same directory as employees. A B2C user is stored in a separate Azure AD B2C tenant, which is completely isolated from your corporate directory. This isolation is a key architectural difference: B2B is an extension of your tenant; B2C is a separate identity store.
Azure AD B2C does not support Azure AD Conditional Access policies directly. However, you can achieve similar functionality using custom policies and integration with Azure AD Identity Protection (premium B2C tiers). For example, you can block sign-ins from risky IP addresses or require MFA based on risk. But the full Conditional Access feature set is not available.
In the Azure portal, go to 'External Identities' > 'Cross-tenant access settings'. Add the partner tenant's ID and configure inbound trust to accept MFA claims. This means if the partner's user has already satisfied MFA at their home tenant, your tenant will honor that and not prompt them again. You can also trust device compliance and hybrid Azure AD join claims.
Yes, you can configure Azure AD as an identity provider in B2C. This allows employees to sign in to customer-facing apps using their corporate credentials. The authentication happens in B2C, but the token is issued by B2C. This is a common pattern for 'employee self-service' portals that are separate from internal systems.
If the guest's home Azure AD tenant is deleted, the guest will no longer be able to authenticate. The guest user object will remain in your tenant as a 'stale' object. You should remove or disable such guests using access reviews or automated cleanup scripts. The guest can also be converted to a member if they have a new identity, but that is not straightforward.
Migration requires careful planning. You need to create a B2C tenant, configure user flows, and update your applications to use B2C endpoints. Existing B2B guest users (customers) can be invited to the B2C tenant via a migration user flow that allows them to re-register. You can use the Microsoft Graph API to export B2B user data and import into B2C. There is no direct migration tool.
You've just covered Entra External Identities: B2B vs B2C Design — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?