This chapter covers authentication and multi-factor authentication (MFA) in Microsoft Entra ID, a core topic for the SC-900 exam. You will learn how Entra ID authenticates users, the protocols used (OAuth 2.0, OpenID Connect, SAML), and how MFA adds security layers. Expect approximately 15-20% of exam questions to touch authentication, MFA, and related conditional access policies. Mastery of this chapter is essential for scoring well on Domain 2 (Identity and Access Management).
Jump to a section
Think of authentication like a hotel key card system. A guest (user) arrives at the hotel (Entra ID) and checks in at the front desk, proving their identity with a photo ID and credit card (username and password). The front desk issues a key card (primary authentication token) that grants access to the room and certain amenities like the gym or pool (authorized resources). However, the hotel knows that key cards can be lost or stolen, so they implement additional verification: to enter the high-security executive lounge (sensitive application), the guest must also present a second form of ID, like a driver's license (MFA second factor). The hotel also has a policy: if a guest tries to access the lounge from a different city within an hour (impossible travel), the front desk calls them to confirm (conditional access). The key card has a magnetic stripe that encodes the guest's room number and check-out date (token claims). When the guest swipes the card at the door, the reader sends the card data to the hotel's central system (Entra ID), which validates the card's expiration (token lifetime) and permissions. If the card is expired (token expired), the guest must revisit the front desk to get a new one (re-authentication). The hotel also uses a mobile app (Microsoft Authenticator) that generates a temporary code (time-based one-time password) for guests who forgot their key card. This analogy shows how authentication establishes identity, MFA adds layers of verification, and conditional access evaluates context before granting access.
What is Authentication in Entra ID?
Authentication is the process of verifying a user's identity. In Microsoft Entra ID (formerly Azure Active Directory), authentication is the foundation for granting access to resources. Entra ID supports multiple authentication methods: passwords, passwordless options (Windows Hello for Business, FIDO2 security keys, Microsoft Authenticator), and federation with external identity providers. The primary authentication flow uses the OpenID Connect (OIDC) protocol, built on OAuth 2.0, to issue ID tokens and access tokens.
Why Authentication Matters for SC-900
The SC-900 exam tests your understanding of how authentication works in Microsoft's identity ecosystem. You need to know:
The difference between authentication (who you are) and authorization (what you can do).
The role of tokens, claims, and identity providers.
How MFA reduces the risk of credential theft.
The authentication methods supported by Entra ID.
How Authentication Works: The Protocol Flow
When a user signs in to an application that uses Entra ID for authentication, the following steps occur:
1. The user navigates to the application (relying party) and clicks Sign In.
2. The application redirects the user to the Entra ID authorize endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize.
3. The user provides credentials (username and password, or passwordless method).
4. Entra ID validates the credentials against its directory. If valid, it issues an ID token (JSON Web Token) that contains claims about the user (e.g., name, email, tenant ID).
5. The ID token is sent back to the application via the browser redirect URI.
6. The application validates the token's signature using the public keys from Entra ID's OpenID Connect discovery endpoint (https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration).
7. If valid, the application creates a session for the user.
For API access, the application also requests an access token using the OAuth 2.0 authorization code flow. The access token is used to call Microsoft Graph or other APIs.
Key Components of Authentication
Identity Provider (IdP): Entra ID acts as the IdP, issuing tokens after successful authentication.
Tokens: JSON Web Tokens (JWTs) that contain claims. ID tokens identify the user; access tokens authorize access to resources.
Claims: Pieces of information about the user (e.g., sub – subject, tid – tenant ID, preferred_username).
Tenant: A dedicated instance of Entra ID. Each tenant has a unique ID (GUID) and domain.
Service Principal: The representation of an application in a tenant, used for authentication and authorization.
Multi-Factor Authentication (MFA)
MFA requires two or more of the following categories:
Something you know (password)
Something you have (phone, hardware token)
Something you are (biometric)
Entra ID MFA supports: - Microsoft Authenticator App: Push notification or time-based one-time password (TOTP) code. - SMS or Voice Call: A code sent via text message or spoken over the phone. - FIDO2 Security Keys: Hardware keys that use public-key cryptography. - Windows Hello for Business: Biometric and PIN-based sign-in on Windows devices. - OATH Tokens: Software or hardware tokens that generate TOTP codes.
MFA is enforced via Conditional Access policies or per-user MFA settings. For SC-900, know that Conditional Access is the preferred method for granular control.
How MFA Works in Practice
When a user attempts to sign in and MFA is required: 1. The user enters their password (first factor). 2. Entra ID evaluates the Conditional Access policy (if any) and determines MFA is needed. 3. The user is prompted to provide the second factor (e.g., approve a push notification on their phone). 4. The user approves the notification or enters a code. 5. Entra ID validates the second factor and issues the token.
Passwordless Authentication
Passwordless methods eliminate the password as a primary factor. Examples: - Microsoft Authenticator App: Allows sign-in with a number match on the phone. - FIDO2 Security Keys: Uses public/private key pair; the private key never leaves the device. - Windows Hello for Business: Uses biometric or PIN tied to the device's TPM (Trusted Platform Module).
For SC-900, understand that passwordless reduces phishing risk because no password is transmitted.
Authentication Protocols
OpenID Connect (OIDC): Built on OAuth 2.0. Used for modern applications (web, mobile, single-page apps). Issues ID tokens and access tokens.
SAML 2.0: Used for enterprise applications, especially in on-premises federated environments. Issues SAML assertions (XML-based).
WS-Federation: Legacy protocol, still used by some Microsoft 365 services.
Conditional Access and Authentication
Conditional Access policies can require MFA based on:
User or group membership
IP location (known vs. unknown)
Device platform (iOS, Android, Windows)
Application sensitivity
Sign-in risk (from Identity Protection)
The policy is evaluated after the user authenticates but before access is granted.
Security Defaults
Security Defaults is a baseline set of security policies enabled for all tenants. It enforces:
MFA for all users
Blocking legacy authentication (e.g., POP3, IMAP, older Office clients)
Requiring MFA for privileged roles
For SC-900, know that Security Defaults are suitable for small organizations, but larger ones should use Conditional Access for more granularity.
Legacy Authentication
Legacy authentication protocols (POP, IMAP, SMTP, etc.) do not support MFA. Blocking them is a key security recommendation. Conditional Access can block legacy authentication globally.
Identity Protection
Identity Protection uses machine learning to detect risky sign-ins. It calculates a risk level (low, medium, high) and can trigger MFA or block access automatically. It integrates with Conditional Access.
Default Values and Timers
Token Lifetime: Access tokens default to 1 hour; refresh tokens up to 90 days if not revoked.
Session Lifetime: Configurable via Conditional Access session controls. Default is until browser is closed.
MFA Remember: Users can mark a device as 'trusted' for up to 60 days (configurable) to skip MFA prompts.
Password Expiration: Default is 90 days for cloud-only users; Microsoft recommends disabling expiration and using password protection policies.
Configuration and Verification
To configure MFA in Entra ID: 1. Navigate to Entra admin center > Identity > Users > Per-user MFA (legacy) or use Conditional Access. 2. For Conditional Access: Create a policy targeting users, apps, conditions, and grant controls requiring MFA.
To verify MFA status:
# Using Microsoft Graph PowerShell
Get-MgUser -UserId user@domain.com | Select-Object DisplayName, UserPrincipalName, @{N="MFAStatus";E={$_.StrongAuthenticationRequirements}}To test authentication flow:
Use the 'Test' feature in Conditional Access policy to simulate sign-in.
Use Azure AD Authentication Methods activity report.
User Initiates Sign-In
The user navigates to an application (e.g., Office 365 portal) and clicks Sign In. The application constructs an authentication request to Entra ID's authorize endpoint. For OIDC, the request includes the client ID, redirect URI, response type (code), and scope (e.g., openid profile). The browser is redirected to login.microsoftonline.com.
Entra ID Presents Login Prompt
Entra ID displays the sign-in page. If the user's tenant has custom branding, that appears. The user enters their username (UPN) and password. Entra ID checks if the account exists, if the password is correct, and if the user is not blocked (e.g., due to risk).
Conditional Access Evaluation
After primary authentication, Entra ID evaluates all applicable Conditional Access policies. It checks conditions like location, device compliance, sign-in risk, and application. If MFA is required, the user is prompted for second factor. If block is required, access is denied.
MFA Challenge (if required)
If MFA is required, Entra ID sends a challenge to the user's registered MFA method. For Authenticator push, a notification appears on the phone. The user must approve it or enter a code. For SMS, a code is sent and the user enters it. The MFA server validates the response.
Token Issuance and Redirection
After successful authentication and MFA, Entra ID generates an ID token and optionally an authorization code. The browser is redirected to the application's redirect URI with these tokens. The application validates the token's signature and claims, then creates a session for the user.
Enterprise Scenario 1: Enforcing MFA for Remote Access
A global company with 10,000 employees uses Microsoft 365 and many SaaS apps. They want to enforce MFA for all remote access but allow MFA-less access from the corporate office. The solution: Create a Conditional Access policy targeting all users and all cloud apps. Add a condition for locations: exclude the corporate office IP range (trusted location). Grant control: Require MFA. The policy ensures that any sign-in from outside the office triggers MFA. Performance is not impacted because MFA only adds a few seconds. Common misconfiguration: forgetting to exclude the corporate IPs, causing all users to be prompted for MFA even in the office, leading to complaints. Also, if the corporate IP range changes, the policy must be updated.
Enterprise Scenario 2: Blocking Legacy Authentication
A healthcare organization must comply with HIPAA and wants to prevent attacks using legacy protocols. They create a Conditional Access policy that blocks all legacy authentication clients. The condition is 'Client apps' set to 'Legacy authentication clients'. The grant control is 'Block access'. This policy prevents POP, IMAP, and older Office clients from accessing Exchange Online. However, some users still use Outlook 2010, which uses legacy auth. The helpdesk receives calls; the solution is to upgrade to Outlook 2013 or later. Performance is not an issue as blocking is instantaneous. Common mistake: not applying the policy to all apps, leaving some legacy access open.
Enterprise Scenario 3: Passwordless with FIDO2 Keys
A tech company wants to eliminate passwords to reduce phishing risk. They deploy FIDO2 security keys to all employees. Users register their keys in the Security Info page. Conditional Access policies require MFA, but with passwordless, the key itself is both primary and secondary factor. The authentication flow: user inserts key, enters PIN (something you know), and the key performs cryptographic authentication. This reduces support tickets for password resets. Scale: thousands of keys managed via Intune. Common issue: users losing keys; backup methods (e.g., Authenticator) must be registered.
SC-900 Objective 2.2: Authentication and MFA in Entra
The exam tests your ability to describe the authentication process, compare authentication methods, and explain MFA. Key areas: - Describe what authentication is (verify identity) vs. authorization (grant permissions). - Identify authentication methods: password, passwordless, MFA. - Understand MFA factors: something you know, have, are. - Know MFA methods: Authenticator app, SMS, voice call, FIDO2, Windows Hello. - Explain Conditional Access: policies that require MFA based on conditions. - Differentiate Security Defaults vs. Conditional Access: Security Defaults are pre-defined; Conditional Access is customizable. - Know legacy authentication: why it's dangerous and how to block it.
Common Wrong Answers and Traps
Confusing authentication with authorization: A question asks 'What does MFA provide?' Wrong answer: 'It authorizes access to resources.' Correct: 'It provides additional verification of identity.'
Selecting 'Password' as a MFA factor: MFA requires at least two factors. A single password is not MFA.
Thinking Security Defaults are the same as Conditional Access: Security Defaults are a fixed set of policies; Conditional Access allows custom policies. The exam may ask 'Which is more flexible?' Answer: Conditional Access.
Believing MFA can be enforced per-user only: While per-user MFA exists, the recommended method is Conditional Access. Exam may ask 'What is the modern way to enforce MFA?' Answer: Conditional Access.
Assuming all authentication protocols support MFA: Legacy protocols do not. The exam may ask 'Which protocol cannot be used with MFA?' Answer: POP3.
Specific Numbers and Terms
MFA default remember period: 60 days (configurable).
Security Defaults: enabled by default for new tenants.
Token lifetimes: access tokens 1 hour, refresh tokens up to 90 days.
Authentication methods: 5 main methods (password, phone, Authenticator, FIDO2, Windows Hello).
Number of factors in MFA: 2 or more.
Edge Cases
Guest users: MFA policies can apply to external users via Conditional Access.
B2B collaboration: MFA may be performed by the guest's home tenant.
Emergency access: Break-glass accounts should be excluded from MFA policies to prevent lockout.
How to Eliminate Wrong Answers
Read the question carefully: Is it asking about authentication or authorization? If the scenario involves verifying identity, it's authentication. If it's about granting access to a resource, it's authorization. For MFA, look for keywords like 'additional verification', 'second factor', 'something you have'. If an option mentions 'password only', eliminate it. For legacy authentication, any protocol that doesn't support modern auth (POP, IMAP, SMTP) is a correct answer when blocking.
Authentication verifies identity; authorization grants access.
MFA requires two or more factors: something you know, have, or are.
Conditional Access is the preferred method to enforce MFA in modern environments.
Security Defaults provide a baseline security but are not customizable.
Legacy authentication protocols do not support MFA and should be blocked.
Passwordless methods reduce phishing risk and include Windows Hello, FIDO2, and Authenticator app.
Token lifetimes: access tokens 1 hour; refresh tokens up to 90 days.
MFA remember period defaults to 60 days on trusted devices.
Identity Protection integrates with Conditional Access to require MFA based on risk.
Break-glass accounts should be excluded from MFA policies to prevent lockout.
These come up on the exam all the time. Here's how to tell them apart.
Security Defaults
Pre-defined set of policies
Enforced tenant-wide
Cannot be customized
Suitable for small organizations
No additional licensing required
Conditional Access
Customizable policies
Target specific users, apps, conditions
Requires Azure AD Premium P1 or P2
Granular control (locations, risk, device)
Supports session controls and block
Mistake
MFA means using two different passwords.
Correct
MFA requires two different categories of factors (e.g., password + phone). Two passwords are still one factor (something you know).
Mistake
Security Defaults are the same as Conditional Access policies.
Correct
Security Defaults are a fixed baseline; Conditional Access allows custom policies with granular conditions.
Mistake
Passwordless authentication means no authentication at all.
Correct
Passwordless still requires a factor (e.g., biometric, PIN) but eliminates the password as a primary factor.
Mistake
MFA can be enforced only for cloud applications.
Correct
MFA can be enforced for on-premises applications via Application Proxy or federation.
Mistake
Legacy authentication protocols support MFA.
Correct
Legacy protocols like POP3, IMAP, and SMTP do not support MFA and should be blocked.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Authentication verifies who you are (identity). Authorization determines what you can access (permissions). For example, when you log into Office 365, your password authenticates you. Then Entra ID checks if you have a license to use Exchange Online – that's authorization. The SC-900 exam often asks to differentiate these two concepts.
Entra ID MFA supports: Microsoft Authenticator app (push or TOTP), SMS text message, voice call, FIDO2 security keys, Windows Hello for Business, and OATH hardware/software tokens. For SC-900, know that Authenticator app is the most secure and recommended method.
You can use Security Defaults (simple, no extra license) or Conditional Access (requires Azure AD Premium P1/P2). To use Conditional Access: create a policy targeting all users and all cloud apps, set grant control to 'Require MFA'. Exclude break-glass accounts. This is the modern approach tested on SC-900.
Legacy authentication uses older protocols like POP3, IMAP, SMTP, and older Office clients that don't support MFA. Attackers often target these because they bypass MFA. Blocking them via Conditional Access is a key security recommendation. The exam may ask which protocols are legacy.
Yes, if the on-premises app is published via Azure AD Application Proxy or federated with Entra ID. Application Proxy handles MFA for on-premises apps. For federation, the on-premises identity provider can enforce MFA. The SC-900 exam may test this scenario.
Access tokens default to 1 hour. Refresh tokens can last up to 90 days. These values can be changed via Conditional Access session controls. The exam may ask about default values.
Passwordless methods like Windows Hello use a PIN or biometric tied to the device's TPM. FIDO2 keys use public-key cryptography: the private key never leaves the device. Microsoft Authenticator app uses number matching. No password is transmitted, reducing phishing risk.
You've just covered Authentication and MFA in Entra — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?