Recommend an Authentication Solution — Lesson

This lesson aligns with AZ-305 Chapter 2, §2.1–2.2, p. 41–65 and covers the architecture and design considerations for authenticating users and applications in Azure. We focus on Microsoft Entra ID (formerly Azure AD) as the identity platform, multi-factor authentication (MFA), Conditional Access policies, passwordless authentication methods, and authentication protocols such as SAML 2.0, OAuth 2.0, and OpenID Connect (OIDC). This is not a lesson on identity governance or lifecycle management (see LO-5), nor on authorization and RBAC (see LO-6/LO-7) — it is about how to verify who someone is when they attempt to access resources.

Reference: Ch. 2, §2.1–2.2, p. 41–65 of the AZ-305 exam book.

Why This Matters

Authentication is the foundation of every secure Azure architecture. Microsoft reports that organisations enabling MFA block over 99.9% of account-compromise attacks. As an architect designing infrastructure for financial services, healthcare, or enterprise SaaS, you must choose between basic username-password, multi-factor methods, passwordless approaches, and federation patterns. The wrong choice costs companies millions in downtime and compliance fines — the right choice enables a workforce to be productive, mobile, and secure. The AZ-305 exam tests your ability to match authentication mechanisms to real-world constraints: device fleets, regulatory mandates, user populations, and risk tolerance.

Prerequisites

• Authentication vs. authorisation — Can you explain why verifying who someone is (authentication) is separate from deciding what they can do (authorisation)? Self-check: if a user passes MFA but has no RBAC role, can they read a Storage blob?
• Entra ID tenant basics — Do you know what a tenant is and how it isolates users? Self-check: can a user in Tenant A directly sign in to resources in Tenant B without an invitation?
• Token-based access — Can you describe why APIs accept tokens instead of passwords? Self-check: what happens when a JWT access token expires — does the user re-enter their password?
• Hybrid identity awareness — Do you know the difference between cloud-only and synced (hybrid) identities? Self-check: what tool synchronises on-premises AD users to Entra ID?

Learning Objectives

By the end of this lesson you will be able to:

1. Analyse authentication requirements across on-premises, cloud, and hybrid identity scenarios and recommend the appropriate Entra ID deployment model.
2. Evaluate MFA methods and Conditional Access policies against organisational risk profiles and design a policy framework that balances security with usability.
3. Design passwordless authentication implementations using FIDO2 security keys, Windows Hello for Business, and Microsoft Authenticator passwordless sign-in.
4. Recommend the correct authentication protocol (SAML 2.0, OAuth 2.0, OIDC) for federation with third-party identity providers or SaaS applications.
5. Architect managed-identity solutions for Azure workloads that eliminate stored secrets.
6. Assess B2C and external-identity scenarios for customer-facing and partner-facing applications.

Building Blocks

Entra ID (formerly Azure Active Directory) — Analogy: Azure's phone book and security guard rolled into one — the phone book lists all users and apps, and the guard checks ID before letting anyone in. → Formal definition: a cloud-based identity and access management service that authenticates users and apps, manages devices, and enforces policies across Microsoft and third-party cloud applications. → Why it matters: it is the core identity platform for Azure; without it there is no user access, no MFA, no Conditional Access, no federation.

Multi-Factor Authentication (MFA) — Analogy: requiring both a passport and a fingerprint scan to enter a building, rather than just the passport. → Formal definition: a security control that requires two or more independent verification factors — something you know, something you have, something you are — before granting access. → Why it matters: even if passwords are stolen, a second factor is exponentially harder to compromise; MFA reduces breach impact by 99% or more in empirical studies.

Conditional Access — Analogy: a bouncer who lets you in from your home office with just an ID but demands a fingerprint scan if you arrive from airport WiFi because the risk is higher. → Formal definition: a policy-driven authentication mechanism that grants, challenges, or denies access based on real-time signals — location, device health, user risk, application sensitivity. → Why it matters: it enables risk-based authentication, allowing legitimate users seamless access while blocking suspicious logins automatically.

Passwordless Authentication — Analogy: replacing a metal key with a biometric fingerprint reader that is unique to you and impossible to lose or share. → Formal definition: authentication methods that replace or eliminate the password — FIDO2 security keys, Windows Hello for Business (biometric or PIN), certificate-based auth, or Microsoft Authenticator phone sign-in. → Why it matters: passwords are the weakest link; passwordless methods are resistant to phishing and credential stuffing.

Authentication Protocol — Analogy: a standardised handshake between a user, an app, and an identity provider (IdP) so they all know each other and trust the exchange. → Formal definition: a technical specification for exchanging identity information; common ones are SAML 2.0 (XML-based federation), OAuth 2.0 (delegation/authorisation), and OIDC (authentication layer on top of OAuth). → Why it matters: each protocol solves a different problem; choosing the wrong one breaks interoperability or introduces security gaps.

Managed Identity — Analogy: a passport-less identity for an Azure resource (VM, Function, App Service) that Azure automatically manages — the service never stores a secret because Azure vouches for it at runtime. → Formal definition: an identity automatically created and managed by Azure for resources to authenticate to other Azure services without storing credentials. Two types: system-assigned (tied to one resource) and user-assigned (reusable across resources). → Why it matters: it eliminates connection strings and secrets from application code.

Deep Dive

Microsoft Entra ID Authentication Fundamentals

Entra ID is the identity layer for Azure. When a user logs in, Entra ID verifies credentials and issues a token. When an app wants to access another service, it authenticates via Entra ID and receives a token. All Azure resources check tokens from Entra ID to decide who you are.

Tenants and users:

Authentication flows:

[!NOTE] In hybrid scenarios (on-premises Active Directory + Entra ID), you use Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync to synchronise identities. Seamless SSO lets domain-joined users sign in to cloud apps without re-entering credentials.

Multi-Factor Authentication and Conditional Access

MFA is no longer optional for sensitive workloads — it is a best practice and often a compliance requirement.

MFA methods ranked by strength:

Conditional Access policies evaluate signals at sign-in time and make a real-time grant/deny/challenge decision:

[!TIP] Start with a baseline: require MFA for Azure Portal, all admin roles, and sensitive apps. Use "Report-only" mode for 1–2 weeks before enforcing. Review the Entra ID sign-in logs to catch false positives before users are blocked.

Named locations and device compliance:

• A named location is an IP range (e.g., your office CIDR blocks) or country that Entra ID recognises as trusted.
• Device compliance checks whether a device meets Intune security baselines (BitLocker enabled, antivirus active, OS patched).
• Combining named locations + device compliance reduces false positives while maintaining strong security.

Passwordless Authentication

Passwordless eliminates the password entirely — a paradigm shift from "something you know" to "something you have" or "something you are."

FIDO2 security keys:

• A hardware device (USB, NFC, or Bluetooth) storing a private key.
• The key signs a challenge from the server without revealing the private key.
• Phishing-resistant: the key is domain-bound — an attacker cannot redirect it to a fake site.
• Deployment: register keys in the Entra ID portal or via Microsoft Authenticator.

Windows Hello for Business:

• Biometric (face/fingerprint) or PIN on a Windows device.
• Private key stored in the Trusted Platform Module (TPM), a hardware security chip.
• Requires Windows 10+ with TPM 2.0.
• Deploy via Intune or Group Policy.

Microsoft Authenticator passwordless:

• User sees a number-match prompt on their phone, confirms via biometric, done.
• Works cross-platform (iOS, Android) — ideal for BYOD.

Certificate-Based Authentication (CBA):

• Authenticate via X.509 certificate on a smart card or device.
• Common in government (e.g., US federal PIV/CAC) and regulated industries.

[!IMPORTANT] Passwordless does not mean MFA is unnecessary. Defence in depth means layering passwordless + Conditional Access + device compliance. A FIDO2 key satisfies both the "something you have" and "something you are" factors in a single gesture.

Authentication Protocols: SAML, OAuth 2.0, and OIDC

When integrating third-party applications or federating with partners, you must choose a protocol.

When to choose which:

Managed identities for workloads:

When an Azure resource (VM, Function App, Container Instance) needs to authenticate to another Azure service, use a managed identity.

[!WARNING] Never store connection strings or client secrets in application code or config files when a managed identity is available. Secrets in code leak via git history, error logs, and backup files. Use DefaultAzureCredential in your SDK calls — it automatically discovers managed identities at runtime.

B2C and External Identity Scenarios

Microsoft Entra External ID for customers is a separate service from Entra ID, designed for customer-facing consumer identity management.

B2C user flow example (sign-up/sign-in with social providers):

When to use B2C vs. External Identities:

• B2C: you are a SaaS provider or retailer with potentially millions of customer logins; you want full control over the sign-up/sign-in UX.
• External Identities: you are inviting a handful of partner organisations to collaborate inside your Entra ID tenant; they sign in with their home IdP.

Worked Examples

Easy — Single-Tenant Corporate MFA Rollout

Problem: A medium-sized insurance company (500 employees) uses Entra ID for Microsoft 365 and Azure resources. Currently they enforce passwords with no MFA. They must roll out MFA company-wide for SOC 2 Type II compliance. The workforce is 70% in two corporate offices, 30% remote.

Step-by-step solution:

1. Assess current state: check how many users have Microsoft Authenticator installed; identify any legacy apps that cannot support modern auth.
2. Phase 1 (Weeks 1–2): deploy Authenticator via Intune push or manual download. Provide training videos and helpdesk support.
3. Phase 2 (Week 3): enable MFA registration requirement; users register on next sign-in. Allow Authenticator (push), SMS, and FIDO2.
4. Phase 3 (Week 4): create a Conditional Access policy — Condition: all cloud apps, all users; Control: require MFA; Exclusion: 2 break-glass accounts.
5. Monitor: track adoption via Entra ID Authentication Methods Activity report. Follow up with non-compliant users.

[!NOTE] Most users will choose Authenticator (push notification). FIDO2 is ideal for admins and executives — consider it as a Phase 2 initiative.

Medium — Multi-Location Conditional Access with BYOD

Problem: A financial services firm ($2{,}000$ employees) has offices in New York, London, and Singapore. Employees use both personal laptops (BYOD) and corporate devices. They access Azure Portal, Dynamics 365, and custom banking APIs. They need to allow productivity but block risky logins (e.g., new country at 3 AM).

Step-by-step solution:

1. Define named locations: Corporate Network = IP ranges of the three offices; Allowed Countries = US, UK, Singapore.
2. Enable device compliance in Intune: require BitLocker, antivirus, no jailbreak. Non-compliant devices cannot access banking APIs.
3. Create Conditional Access policies:
   • Policy 1 (Sensitive Apps): Apps = Azure Portal + Dynamics + Banking APIs; Device not compliant → require MFA + compliant device.
   • Policy 2 (High Risk): Sign-in risk = high OR user risk = high → require MFA + password change.
   • Policy 3 (Location Block): Location = outside Allowed Countries → block access entirely.
4. Test: use Report-only mode for 1 week, review sign-in logs, adjust.

[!NOTE] Entra ID's impossible-travel detection is automatic. The key is interpreting the risk signals and mapping them to the right control — block vs. step-up MFA vs. allow.

Hard — Hybrid Identity with Federation, B2C, and Managed Identities

Problem: A healthcare company has $1{,}500$ employees on on-premises AD, a patient-facing mobile app ($100{,}000$+ users needing social login), and a backend microservice in Azure Container Instances that reads patient records from Azure SQL Database without storing secrets.

Step-by-step solution:

1. Hybrid identity: deploy Microsoft Entra Cloud Sync to synchronise on-premises AD users to Entra ID. Enable Seamless SSO so domain-joined users sign in to cloud apps automatically.
2. B2C for patients: create a separate Microsoft Entra External ID for customers tenant. Define a sign-up/sign-in user flow with Google, Facebook, and local email. Integrate the mobile app (iOS/Android) via MSAL. B2C returns an ID token + access token on sign-in.
3. Managed identity for the microservice: enable a system-assigned managed identity on the Container Instance. In Azure SQL Database, create a contained database user mapped to the MI. Grant SELECT on patient tables. In code, use DefaultAzureCredential to obtain a token scoped to https://database.windows.net.
4. Conditional Access for employees: require MFA for Salesforce; block high-risk countries; require compliant devices for Azure Portal.

[!NOTE] Three identity systems coexist: on-premises AD (employees, synced to Entra ID), Entra ID (cloud and hybrid), and B2C (patients). Each is isolated and purpose-built.

Visual Explanations

Entra ID Authentication Flow (Mermaid)

Caption: The basic authentication flow. The user provides credentials and MFA; Entra ID validates, evaluates Conditional Access, and issues a JWT. The resource verifies the token and grants access.

Conditional Access Decision Tree (Mermaid)

Caption: Conditional Access evaluates real-time signals (location, device state, risk level) and makes a dynamic decision: allow, challenge with MFA, or block.

Authentication Protocol Comparison (TikZ)

Caption: Evolution and comparison of authentication protocols. SAML 2.0 handles legacy federation, OAuth 2.0 handles API delegation, and OIDC extends OAuth with an authentication layer for modern apps.

Passwordless Methods Comparison Table

Caption: FIDO2 and Windows Hello are phishing-resistant and recommended for high-value accounts. Authenticator is the easiest cross-platform option. SMS should only be a fallback.

Common Mistakes

❌ Myth: "We require MFA for all users, so we are fully secure." ✅ Reality: MFA adds a second factor but does not adapt to risk. If an attacker compromises a password and tricks the user into approving an MFA push (MFA fatigue), they gain access. Conditional Access adds a third dimension: even if MFA passes, it can block access from high-risk locations or non-compliant devices. Why it's tricky: MFA feels like a complete solution because users see the second prompt. Conditional Access is invisible to legitimate users but invaluable against advanced attacks. Many teams stop after enabling MFA.

❌ Myth: "We use SAML for all cloud integrations because it is the enterprise standard." ✅ Reality: SAML was designed in the 2000s for on-premises federation. OIDC, built on OAuth 2.0, is the modern standard for cloud applications and APIs. Most SaaS apps prefer OIDC. Using SAML for a new cloud-native app is like insisting on fax when email is available — it works, but you lose features and integration capabilities. Why it's tricky: SAML is mature and stable; many architects learned it first. The mental model says "SAML = enterprise." But OIDC is now the enterprise standard for cloud; the switch requires updating app registrations but yields simpler code and better API support.

❌ Myth: "We store the database connection string in our app's config. It is in a private repo, so it is safe." ✅ Reality: Secrets in code leak via git history, error logs, deployment artefacts, and backup files. A junior developer commits a secret; it lives in the repo forever. A managed identity eliminates this risk entirely — Azure vouches for the app at runtime with a short-lived token. Why it's tricky: Managed identities require a mental shift from "here is the key, use it" to "Azure will give you a temporary key at runtime." The first approach feels simpler but is architecturally fragile.

❌ Myth: "All users must comply with our Conditional Access policies — no exceptions." ✅ Reality: If a Conditional Access misconfiguration blocks all users — including admins — you lose access to your tenant. You must maintain 2 break-glass (emergency access) accounts excluded from all policies. These accounts have long complex passwords, no MFA, are monitored by alerts, and are only used in emergencies. Why it's tricky: Excluding accounts feels insecure. But 2 heavily guarded break-glass accounts are far safer than a complete tenant lockout with no recovery path.

Practice Exercises

🟢 Easy — A start-up with 50 employees uses Entra ID for Microsoft 365. They have no MFA today. Which single Conditional Access policy should they deploy first?

▶💡 Hint

Think about the highest-risk access point that is also the easiest to protect.

▶✅ Solution

Require MFA for all users accessing all cloud apps. Exclude 2 break-glass accounts. This is the single highest-impact policy and covers the broadest attack surface. At 50 users, a blanket policy is manageable.

🟢 Easy — An app registration in Entra ID returns both an ID token and an access token after sign-in. Which authentication protocol is being used?

▶💡 Hint

SAML uses XML assertions. OAuth 2.0 returns only an access token. Which protocol adds an ID token on top of OAuth?

▶✅ Solution

OpenID Connect (OIDC). It extends OAuth 2.0 by adding an ID token (JWT with identity claims) alongside the access token.

🟡 Medium — A pharmaceutical company has offices in Boston and Toronto. Remote workers use personal laptops. They access a HIPAA-regulated patient records app on Azure App Service. Design a Conditional Access policy set.

▶💡 Hint

Consider: (1) named locations for offices, (2) device compliance for BYOD, (3) the sensitivity of HIPAA data, (4) break-glass exclusions.

▶✅ Solution

Policy 1: Condition = Patient Records App + location not in "Boston" or "Toronto" named locations → Control = require MFA. Policy 2: Condition = Patient Records App + device not Intune-compliant → Control = require MFA + compliant device. Exclusion on both: break-glass accounts and service accounts. This allows office workers frictionless access on compliant devices while remote/BYOD users must satisfy MFA and device compliance.

🟡 Medium — A web app on Azure App Service needs to read secrets from Azure Key Vault. Currently the connection string is in appsettings.json. Redesign this using a managed identity.

▶💡 Hint

Enable a system-assigned managed identity on the App Service. Grant it an access policy on Key Vault. Update the code to use DefaultAzureCredential.

▶✅ Solution

Enable the system-assigned managed identity on the App Service (Bicep: identity: { type: 'SystemAssigned' }). In Key Vault, create an access policy granting Get and List secrets permissions to the App Service's principal ID. In code, replace the connection string with new SecretClient(vaultUri, new DefaultAzureCredential()). Remove the secret from appsettings.json and git history entirely.

🔴 Hard — A logistics company wants to: (a) allow $10{,}000$+ customers to track shipments via a web portal with social login, and (b) allow 5 partner logistics companies to access a shared shipment database (read-only). Should they use Microsoft Entra External ID for customers, Entra ID External Identities, or a combination? Justify.

▶💡 Hint

Consider scale ($10{,}000$+ vs. 5), governance (self-service vs. admin-provisioned), social login needs, and identity isolation.

▶✅ Solution

Customers: Use Microsoft Entra External ID for customers. Rationale: $10{,}000$+ external, unmanaged identities at consumer scale. B2C supports social login (Google, Facebook), self-service sign-up, and is isolated from the corporate tenant. Partners: Use Entra ID External Identities (B2B guest). Rationale: only 5 known organisations; invite their users as guests. They sign in with their home IdP and inherit your Conditional Access policies. Architecture: two separate identity systems — B2C for customers (public portal) and Entra ID for partners (governed, internal). This ensures compliance (customers never touch the corporate tenant) and appropriate scale.

🔴 Hard — A healthcare company has on-premises AD ($1{,}500$ employees), a patient mobile app ($100{,}000$+ users), and a backend microservice in Azure Container Instances that reads from Azure SQL Database. Design the complete authentication architecture covering all three identity populations.

▶💡 Hint

Think: (1) hybrid identity for employees, (2) B2C for patients, (3) managed identity for the microservice. How do these three coexist?

▶✅ Solution

Employees: deploy Microsoft Entra Cloud Sync to synchronise on-prem AD to Entra ID. Enable Seamless SSO for domain-joined devices. Apply Conditional Access policies (MFA for sensitive apps, compliant devices for Azure Portal). Patients: create a separate Microsoft Entra External ID for customers tenant. Define a sign-up/sign-in user flow with Google, Facebook, and local email. The mobile app uses MSAL to authenticate and receives ID + access tokens. Microservice: enable a system-assigned managed identity on the Container Instance. Create a contained database user in Azure SQL mapped to the MI. Grant db_datareader. In code, use DefaultAzureCredential for token-based SQL auth. Result: three isolated identity systems, zero stored secrets, strong MFA for employees, frictionless social login for patients.

Summary & Concept Map

• Entra ID is the foundational identity platform for every Azure authentication scenario — employees, apps, and services all authenticate through it.
• MFA + Conditional Access together form the modern security baseline: MFA alone is insufficient; Conditional Access adds risk-adaptive, context-aware enforcement.
• Passwordless methods (FIDO2, Windows Hello for Business, Microsoft Authenticator) eliminate the weakest link — the password — and should be the target state for all organisations.
• OIDC is the modern standard for SaaS and cloud app integration; use SAML 2.0 only for legacy federation scenarios that do not support OIDC.
• Managed identities eliminate stored secrets for Azure workloads — always prefer them over connection strings or client secrets.
• Use B2C for consumer-scale external identity (social login, self-service) and External Identities for governed B2B partner collaboration.
• Always maintain 2 break-glass accounts excluded from all Conditional Access policies to prevent tenant lockout.