Choosing Authentication Methods
PHS, PTA, or federation? B2B or B2C? Passwordless or traditional MFA? Every Azure architecture starts with an authentication decision — and the wrong one creates technical debt for years.
Why authentication design matters
Authentication is the front door to your Azure solution. Get it wrong, and either nobody can get in (bad UX) or the wrong people get in (security breach).
The three big questions: How do users prove who they are? (passwords, MFA, passwordless), Where does identity live? (cloud-only, hybrid with on-prem AD), and Who are the users? (employees, partners, customers).
AZ-305 expects you to choose the right authentication topology for a given scenario — considering security requirements, user experience, and infrastructure constraints.
Hybrid identity: connecting on-prem AD to Entra ID
Most enterprises still have on-premises Active Directory. The question isn’t IF to connect them — it’s HOW.
| Factor | Password Hash Sync (PHS) | Pass-Through Authentication (PTA) | Federation (ADFS) |
|---|---|---|---|
| How it works | Hash of password hash synced to Entra ID | Auth request forwarded to on-prem agent in real-time | Auth redirected to on-prem ADFS farm |
| On-prem dependency for auth | None — Entra handles auth even if on-prem is down | Yes — needs on-prem agent running | Yes — needs ADFS farm running |
| Infrastructure required | Entra Connect Sync only | Entra Connect Sync + PTA agents (2+ for HA) | ADFS farm + WAP servers + certificates |
| Password policies | Entra ID policies (cloud) | On-prem AD policies enforced | On-prem AD policies enforced |
| Leaked credential detection | Yes — Entra ID Protection checks hash against known breaches | No — password never leaves on-prem | No — password never leaves on-prem |
| Complexity | Low | Medium | High |
| Best for | Most organisations — simplest, most resilient | Orgs requiring on-prem password policy enforcement | Orgs needing advanced federation (smart cards, 3rd-party MFA) |
🏗️ Priya’s decision: GlobalTech has 10,000 users on on-prem AD. Priya chose PHS + Seamless SSO because:
- Cloud auth works even during the data centre migration (on-prem might have downtime)
- Leaked credential detection catches compromised accounts immediately
- Lowest infrastructure overhead — no PTA agents or ADFS farms to maintain
Exam tip: PHS is almost always the recommended answer
Microsoft’s official guidance recommends PHS as the primary authentication method for most scenarios. PTA and ADFS are for specific requirements:
- PTA: “Our security policy mandates that password hashes never leave our network” (regulatory requirement)
- ADFS: “We need smart card authentication” or “We use a third-party MFA provider that requires federation”
If the exam scenario doesn’t mention a specific constraint that blocks PHS, choose PHS.
External identity: B2B vs B2C
Not all users are employees. Two distinct patterns for external access:
| Factor | Entra ID B2B | Entra External ID (B2C) |
|---|---|---|
| Who are the users? | Partners, vendors, contractors — people with their own org identity | Consumers, customers — people with personal accounts |
| Identity source | Guest's home tenant, Google, Microsoft account, email OTP | Local accounts, social providers (Google, Facebook, Apple) |
| Directory | Guest objects in YOUR tenant | Separate B2C tenant/directory |
| App registration | Apps registered in your tenant | Apps registered in B2C tenant |
| Branding | Your tenant's sign-in page | Fully customisable sign-in flows (user journeys) |
| Scale | Thousands of partners | Millions of consumers |
| Licensing | Free for first 50K MAU, then per-MAU | Free for first 50K MAU, then per-MAU |
| Best for | SharePoint sharing, Teams collaboration, Azure portal access for partners | Customer-facing apps, e-commerce, SaaS platforms |
🚀 Marcus’s architecture: NovaSaaS has two external identity needs:
- B2B: Partner companies who integrate with NovaSaaS’s API — invited as guests, access the partner portal via their own corporate identity
- B2C: End customers who sign up for the SaaS product — use Entra External ID with social logins (Google, Microsoft) + local email accounts
Passwordless authentication
The future of authentication. AZ-305 expects you to know when to recommend each method.
| Method | FIDO2 Security Keys | Windows Hello for Business | Microsoft Authenticator (Passwordless) |
|---|---|---|---|
| Form factor | Physical USB/NFC key | Built into Windows device (biometric/PIN) | Phone app push notification |
| Works on | Any device with USB/NFC + browser support | Windows 10/11 devices only | iOS/Android phone required |
| Phishing resistant? | Yes — hardware-bound, origin-verified | Yes — device-bound, TPM-backed | Partially — number matching helps, but phone-based |
| Best for | Shared workstations, kiosks, high-security environments | Corporate-managed Windows devices | BYOD, mobile workforce, broad rollout |
| Infrastructure needs | Key purchasing + registration | Windows Hello provisioning, TPM | Authenticator app deployment |
Exam tip: Phishing-resistant MFA
AZ-305 increasingly tests awareness of phishing-resistant authentication. Traditional MFA (SMS, phone call) can be intercepted via SIM-swap or social engineering. FIDO2 and Windows Hello for Business are hardware/device-bound and verify the origin of the authentication request — making phishing nearly impossible. If a scenario mentions “high security” or “prevent credential phishing,” recommend FIDO2 or Windows Hello.
Conditional Access: context-aware authentication
Conditional Access policies are the engine of Zero Trust authentication. They evaluate signals (user, device, location, risk) and enforce controls (allow, block, require MFA, require compliant device).
Design patterns
| Pattern | Signals | Control | Example |
|---|---|---|---|
| Risk-based MFA | Sign-in risk (Entra ID Protection) | Require MFA when risk is medium+ | Unusual travel triggers MFA challenge |
| Device compliance | Intune compliance status | Require compliant device | Block unmanaged devices from sensitive apps |
| Location-based | Named locations (IP ranges, countries) | Block or require MFA outside trusted locations | Allow office IPs, require MFA from home |
| App-based | Target specific cloud apps | Different controls per app | Azure portal requires MFA; Teams allows SSO |
🏦 Elena’s layered approach: FinSecure Bank’s Conditional Access design:
- All users: MFA required for all cloud apps (baseline)
- Admins: Phishing-resistant MFA (FIDO2 only) + compliant device required
- External access: Block all countries except operating regions
- High-risk sign-ins: Automatic password reset + MFA
Well-Architected Framework connection
Security: Conditional Access is the primary implementation mechanism for Zero Trust “verify explicitly” principle. Every access request is evaluated against multiple signals.
Reliability: Design Conditional Access with “break glass” emergency access accounts excluded from all policies. If your MFA provider goes down, you still need admin access.
User Experience (Operational Excellence): Overly aggressive CA policies create friction. Use risk-based policies to challenge only when the signal warrants it — not every single sign-in.
Knowledge check
🏗️ GlobalTech is migrating 10,000 users to Azure. Their security team requires that password hashes never leave the corporate network, and they need real-time enforcement of on-premises password policies. Which hybrid identity approach should Priya recommend?
🚀 NovaSaaS needs to let partner companies access their API portal using their own corporate credentials, while also allowing consumer customers to sign up with Google or email accounts. Which combination should Marcus recommend?
Next up: Authentication tells you WHO someone is. Now let’s design HOW identities are managed — Designing Identity Management.