Design 23: Azure AD B2C (External Identity)

Summary

This design manages Customer Identity (CIAM). Instead of storing passwords in your SQL database (dangerous), you offload login to Azure AD B2C.

Topology: The B2C Tenant is a separate directory. Your Application (in the Spoke VNet) trusts B2C via OIDC.

1. Key Design Decisions (ADR)

ADR-01: Directory Strategy

Decision: Use a separate B2C Tenant.
Rationale: Isolates customer identities (millions of users) from corporate employees (Entra ID).

ADR-02: Protocol

Decision: Use OpenID Connect (OIDC).
Rationale: Modern, standard authentication protocol supported by all web frameworks.

2. High-Level Design (HLD)

+--------------+           +--------------------------+           +--------------+
|  Customer    |           |        Azure AD B2C      |           |  SPOKE VNet  |
|  (Browser)   |           |        (Identity)        |           |  (Web App)   |
|              |           |                          |           |              |
+------+-------+           +------------+-------------+           +------+-------+
       |                                ^                                ^
       | (1) Login Request              |                                |
       +--------------------------------+                                |
       |                                                                 |
       | (2) Token Issued (JWT)                                          |
       v                                                                 |
       +-----------------------------------------------------------------+
       | (3) Access App with Token
       v

3. Low-Level Design (LLD)

                               PRIMARY REGION (East US)
+-----------------------------------------------------------------------+
| SPOKE VNet: vnet-app-spoke                                            |
|   +-----------------------+                                           |
|   | Web App (PaaS/VM)     |                                           |
|   | Config:               |                                           |
|   | - ClientID: xyz       |                                           |
|   | - Authority: b2c.com  |                                           |
|   +-----------------------+                                           |
+---------------|-------------------------------------------------------+
                |
                | (Geo-Redundant App)
                v
+-----------------------------------------------------------------------+
| SECONDARY REGION (West US) - DR Site                                  |
|                                                                       |
|   +-----------------------+                                           |
|   | Web App (Standby)     |                                           |
|   | Config:               |                                           |
|   | - Same B2C Settings   |                                           |
|   +-----------------------+                                           |
+-----------------------------------------------------------------------+

*Note: B2C Service itself is Global and Highly Available by Microsoft.

4. Component Rationale

User Flow: Pre-built pages for "Sign Up", "Sign In", "Password Reset".
App Registration: Represents your code in the B2C directory.

5. Strategy: High Availability (HA)

B2C Service: 99.9% SLA. Global service.
App: Deploy App in multiple zones/regions.

6. Strategy: Disaster Recovery (DR)

Identity: B2C handles its own replication.
App: If East US App fails, Traffic Manager routes users to West US App. The West US App uses the *same* B2C tenant, so users don't notice anything.

7. Strategy: Backup

Users: B2C does not have a "Restore User" button. You must rely on Microsoft's resilience or export users periodically via Graph API (complex).

8. Strategy: Security

MFA: Enable Multi-Factor Auth in the User Flow (SMS/Email).
Token: The App validates the JWT signature to ensure it came from B2C.

9. Well-Architected Framework Analysis

Reliability: High.
Security: High. No passwords stored in your DB.
Cost Optimization: Excellent. First 50,000 MAU (Monthly Active Users) are Free.
Operational Excellence: High. Self-service password reset reduces helpdesk calls.
Performance Efficiency: High.

10. Detailed Traffic Flow

1. User: Clicks "Login" on myapp.com.

2. Redirect: App redirects browser to contoso.b2clogin.com.

3. Auth: User enters email/password (or Google login).

4. Token: B2C validates creds, issues ID Token. Redirects back to myapp.com/callback.

5. Session: App validates token, creates a session cookie.

11. Runbook: Deployment Guide (Azure Portal)

Phase 1: Create B2C Tenant

1. Search: "Azure AD B2C" -> + Create.

2. Create a new Azure AD B2C Tenant.

3. Organization name: ContosoCustomer[UniqueId].

4. Initial domain name: contosocust[uniqueid].onmicrosoft.com.

5. Location: United States.

6. Subscription: Select yours.

7. Resource Group: Create rg-b2c.

8. Create.

* *Note: This creates a completely separate Directory/Tenant.*

Phase 2: Switch Directory (Critical Step)

1. Wait for deployment to finish.

2. Click the Open new B2C Tenant link (or go to Portal Settings -> Directories).

3. Switch to the ContosoCustomer[UniqueId] directory.

* *You will see the portal reload. You are now "inside" the B2C tenant.*

Phase 3: Register App

1. Search: "App registrations" (Inside B2C Tenant).

2. + New registration.

3. Name: WebApp1.

4. Supported account types: Accounts in any identity provider or organizational directory (for authenticating users with user flows).

5. Redirect URI: Web -> https://jwt.ms (Great tool for debugging tokens).

6. Register.

7. Copy the Application (client) ID. Save it.

Phase 4: Create User Flow

1. Search: "User flows".

2. + New user flow.

3. Select: Sign up and sign in. -> Create.

4. Name: B2C_1_susi (Prefix B2C_1_ is auto-added usually, or you add it).

5. Identity providers: Email signup.

6. User attributes and token claims:

* Click Show more.

* Select City, Display Name, Given Name, Surname.

* Click OK.

7. Create.

Phase 5: Test

1. Click B2C_1_susi.

2. Click Run user flow.

3. A popup opens. Sign up as a fake user.

4. After signup, it redirects to jwt.ms and shows your Token. Success!