This chapter covers the fundamental concepts of authentication and authorisation, which are core to Microsoft's identity and access management solutions. Understanding the difference is critical for the SC-900 exam, as questions on identity concepts appear in roughly 15-20% of the exam. You will learn the mechanisms, protocols, and Microsoft implementations that distinguish these two processes, along with common exam traps and misconceptions.
Jump to a section
Authentication is like checking in at a hotel front desk. You present your ID (credentials) and the clerk verifies you are who you claim to be. Once verified, the clerk issues you a key card (token) that opens your specific room door. The key card does not prove you are the guest; it proves you were authenticated. Authorisation is what the key card allows you to do: open your room (specific resource), use the gym (another resource), but not enter the staff office (restricted). The lock on each door checks the key card's permissions, not your identity. If you lose the card, anyone can use it until it is deactivated. In IT, authentication answers "Who are you?" and authorisation answers "What are you allowed to do?" The hotel clerk (identity provider) authenticates you; the door locks (resource systems) authorise based on the card's data. Multi-factor authentication is like needing both your ID and a PIN to get the key card. Just as a key card alone doesn't grant access to all floors, an authenticated user doesn't automatically have access to all resources.
What is Authentication?
Authentication is the process of verifying the identity of a user, device, or service. It answers the question "Who are you?" In Microsoft's identity stack, authentication involves presenting credentials (something you know, have, or are) and having them validated against an identity store like Azure Active Directory (Azure AD). The result is a security token that proves the authentication event occurred, but does not itself grant access to resources.
What is Authorisation?
Authorisation is the process of determining what an authenticated identity is allowed to do. It answers "What can you access?" After authentication, the authorisation process evaluates policies, roles, and permissions to decide whether to grant or deny access to a specific resource (e.g., a file, an app, an API). In Microsoft 365, authorisation is often managed via Azure RBAC, Azure AD roles, or resource-specific permissions.
The Authentication vs Authorisation Separation
These two processes are logically separate but chained. A user must first authenticate before authorisation can occur. However, authentication alone does not imply authorisation — a user can be authenticated but denied access to a resource. Conversely, authorisation cannot happen without prior authentication. In protocols like OAuth 2.0 and OpenID Connect, the separation is explicit: OpenID Connect handles authentication (identity layer), while OAuth 2.0 handles authorisation (delegated access).
How Authentication Works in Microsoft Identity
User initiates sign-in: The user navigates to a resource (e.g., portal.office.com) and is redirected to Azure AD's sign-in endpoint.
Credential collection: Azure AD presents a login page. The user enters username and password (something you know). Optionally, MFA prompts for a second factor (something you have like a phone, or something you are like a fingerprint).
Credential validation: Azure AD validates the credentials against its directory. For federated domains, validation may be delegated to an on-premises ADFS or other IdP.
Token issuance: Upon successful validation, Azure AD issues an ID token (OpenID Connect) and an access token (OAuth 2.0). The ID token contains claims about the user's identity (e.g., sub, name, email). The access token contains claims used for authorisation.
Token presented to resource: The client (e.g., browser, app) presents the access token to the resource server (e.g., SharePoint Online, Microsoft Graph API).
How Authorisation Works in Microsoft Identity
Token validation: The resource server (e.g., Exchange Online) receives the access token. It validates the token's signature, issuer, audience, and expiry.
Claims extraction: The resource server extracts claims from the token, such as the user's object ID, roles, and scopes.
Policy evaluation: The resource server evaluates its own authorisation policies. For example, SharePoint checks the user's permissions on the specific site or document.
Access decision: If the user has the required permissions (e.g., read, write), access is granted; otherwise, an HTTP 403 Forbidden is returned.
Key Components and Defaults
Authentication Methods: Passwords, Windows Hello for Business, FIDO2 security keys, Microsoft Authenticator app, SMS, voice call, OATH tokens.
MFA Defaults: Microsoft enforces MFA for admin roles by default. Conditional Access policies can require MFA for all users.
Token Lifetimes: Access tokens default to 1 hour, but can be configured from 10 minutes to 24 hours. Refresh tokens default to 90 days of inactivity.
Session Timeouts: Azure AD session token (non-persistent cookie) defaults to 8 hours; persistent cookie to 24 hours.
Password Policies: Azure AD default password expiration is 90 days (but Microsoft recommends disabling expiration). Password length minimum is 8 characters.
Protocols and Standards
OpenID Connect: Identity layer on top of OAuth 2.0. Used for authentication in Azure AD. Returns an ID token (JWT).
OAuth 2.0: Authorisation framework. Used for delegated access. Returns an access token (JWT) with scopes.
SAML 2.0: Used for federated authentication with Azure AD. Exchanges SAML assertions.
WS-Federation: Legacy protocol used with ADFS.
Kerberos: Used in hybrid scenarios for on-premises resources.
Conditional Access and Authorisation
Conditional Access is an Azure AD feature that evaluates signals (user, device, location, risk) to enforce authorisation policies before granting access. It is not authentication itself; it is an authorisation gate that can require MFA, block access, or limit session. For example, a policy might require MFA when accessing from an untrusted location, but allow single-factor from the corporate network.
Exam-Relevant Numbers and Values
Access token default lifetime: 1 hour (60 minutes). Configurable via PowerShell.
Refresh token lifetime: 90 days without use.
Session token (non-persistent): 8 hours.
Session token (persistent): 24 hours.
MFA enforcement: Required by default for Global Administrators, Security Administrators, Conditional Access Administrators, Exchange Administrators, SharePoint Administrators, and others.
OAuth 2.0 grant types: Authorization Code (most common for web apps), Client Credentials (for daemon/service apps), Device Code (for input-constrained devices), Resource Owner Password Credentials (legacy, not recommended).
Common Exam Traps
Trap: Confusing authentication with authorisation: A question might describe a scenario where a user can access a resource but is denied a specific action. The correct answer is authorisation, not authentication.
Trap: Thinking MFA is authorisation: MFA is an authentication enhancement, not an authorisation control. It verifies identity more strongly.
Trap: Believing conditional access is authentication: Conditional Access is an authorisation decision engine that uses authentication signals.
Trap: Overlooking token validation: Authorisation always involves token validation; if a token is invalid, access is denied regardless of permissions.
How Authentication and Authorisation Interact with Related Technologies
Azure AD B2B: Guest users authenticate in their home tenant, but authorisation is based on resource tenant policies.
Azure AD B2C: Customer-facing authentication with local accounts or social IdPs; authorisation is handled by the application.
Managed Identities: Provide an automatically managed identity for Azure resources to authenticate to Azure AD, then authorisation is via RBAC.
Service Principals: Used for application authentication; authorisation is granted via app permissions (delegated or application).
Configuration and Verification Commands
To check token lifetimes via Azure AD PowerShell:
Get-AzureADPolicy | Where-Object {$_.Type -eq "TokenLifetimePolicy"}To create a token lifetime policy:
New-AzureADPolicy -Definition @('{"TokenLifetime":{"AccessTokenLifetime":"01:00:00"}}') -DisplayName "DefaultPolicy" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"To verify authentication logs in Azure AD:
Get-AzureADAuditSignInLogs -Filter "createdDateTime ge 2023-01-01"In the Azure portal, sign-in logs show authentication status, MFA details, and conditional access policies that were evaluated.
User Initiates Authentication
The user attempts to access a resource, such as the Azure portal or SharePoint Online. The application redirects the user to the Azure AD sign-in endpoint (login.microsoftonline.com). The browser sends an HTTP 302 redirect with an OpenID Connect authentication request containing the client ID, redirect URI, response type (code), and scope (openid profile email). Azure AD receives the request and prepares the sign-in page.
Credential Validation
The user provides their username and password. Azure AD validates the password hash against its directory. If MFA is required, a second factor is prompted (e.g., Microsoft Authenticator push notification). The user completes the MFA challenge. Azure AD may also evaluate device compliance (Intune) and sign-in risk (Identity Protection). If validation fails, an error is returned; if successful, Azure AD creates an authentication session.
Token Issuance
Upon successful authentication, Azure AD generates an ID token and an access token. The ID token is a JWT containing claims like 'sub' (subject identifier), 'name', 'preferred_username', 'oid' (object ID), and 'tid' (tenant ID). The access token includes claims such as 'aud' (audience resource), 'scp' (scopes), and 'roles'. Tokens are digitally signed using Azure AD's private key and have a default lifetime of 1 hour.
Token Presentation to Resource
The client (browser or app) sends the access token to the resource server (e.g., Microsoft Graph API) in the HTTP Authorization header as a Bearer token. The request might be a GET to https://graph.microsoft.com/v1.0/me. The resource server receives the token and begins validation.
Authorisation Decision
The resource server validates the token: checks signature using Azure AD's public keys, verifies the audience ('aud') matches its own identifier, ensures the token is not expired, and confirms the issuer ('iss') is the expected tenant. Then it extracts claims like 'scp' (delegated permissions) or 'roles' (application permissions). It evaluates its internal authorisation policies—e.g., does the user have the required permission to read their profile? If yes, the resource returns data (HTTP 200). If not, it returns HTTP 403 Forbidden.
Enterprise Scenario 1: Hybrid Identity with MFA
A large enterprise uses Azure AD Connect to synchronise on-premises Active Directory to Azure AD. They enforce MFA for all cloud app access via Conditional Access. When a user signs into Office 365 from a remote location, authentication first validates their password against Azure AD (synced hash). Conditional Access then evaluates the user's location (untrusted IP) and requires MFA. The user completes MFA via the Authenticator app. After authentication, authorisation for Exchange Online checks the user's mailbox permissions via RBAC. Common misconfiguration: not excluding the on-premises MFA server from conditional access policies, causing double MFA prompts.
Enterprise Scenario 2: App-to-App Authentication with Managed Identities
A company runs an Azure Function that reads from Azure Blob Storage. Instead of storing credentials, they enable a system-assigned managed identity on the Function. At runtime, the Function authenticates to Azure AD via the managed identity endpoint (169.254.169.254). Azure AD issues an access token for the Storage resource. The Function presents this token to Blob Storage, which validates it and checks RBAC: the managed identity has 'Storage Blob Data Reader' role on the storage account. Authorisation succeeds. Common pitfall: forgetting to assign RBAC roles to the managed identity, resulting in 403 errors.
Enterprise Scenario 3: B2B Collaboration
A company invites external partners as guest users in Azure AD. When a guest signs in, they authenticate in their home tenant (e.g., Google or another Azure AD tenant). Their home tenant issues an ID token. Azure AD then maps the guest to a user object in the resource tenant and issues an access token for the resource tenant's apps. Authorisation is based on guest user permissions (e.g., SharePoint site access). Common issue: guests are not assigned to groups or roles, so they see a blank portal. Performance: token exchange adds latency, but Azure AD caches guest tokens for 1 hour.
What SC-900 Tests on This Topic
The SC-900 exam objective 'Describe the concepts of identity' (1.1) and 'Describe the concepts of authentication and authorisation' (1.2) are tested together. Expect 3-5 questions that directly ask you to differentiate authentication from authorisation. The exam uses scenario-based questions: e.g., 'A user can log in but cannot access a file. Which process failed?' The answer is authorisation. Another common scenario: 'Which process validates a user's password?' Answer: authentication.
Common Wrong Answers and Why
Choosing 'Conditional Access' as authentication: Many candidates think Conditional Access is part of authentication because it runs during sign-in. But Conditional Access is an authorisation control that evaluates policies after authentication.
Selecting 'MFA' as authorisation: MFA is an authentication method, not an authorisation decision. Authorisation is about permissions, not how you prove identity.
Mixing up 'authentication' and 'authorisation' in Azure RBAC: RBAC is authorisation; the user must already be authenticated to receive a token.
Thinking that a user who is denied access has an authentication failure: Denial after login is almost always authorisation, not authentication.
Specific Numbers and Terms on the Exam
Token lifetime: 1 hour for access tokens, 90 days for refresh tokens (inactivity).
Kerberos vs OAuth: Kerberos is used for on-premises authentication; OAuth for cloud.
OpenID Connect: For authentication; returns ID token.
OAuth 2.0: For authorisation; returns access token.
SAML: For federation; returns assertion.
Claims: Pieces of identity information in tokens (e.g., email, role).
Edge Cases and Exceptions
Guest users: Authentication happens in their home tenant; authorisation in resource tenant.
Managed identities: Authentication is handled by Azure automatically; authorisation via RBAC.
Service principals: Authenticate via client secret or certificate; authorisation via app permissions.
Conditional Access: Can block authentication altogether (e.g., sign-in risk too high) — this is still authorisation by policy, not authentication failure.
How to Eliminate Wrong Answers
If the question mentions 'password', 'biometrics', 'MFA', 'token issuance' → it's authentication.
If the question mentions 'permissions', 'roles', 'access control', 'policy', 'allowed/denied' → it's authorisation.
If the question mentions 'Conditional Access', 'RBAC', 'Azure AD roles' → it's authorisation.
If the question mentions 'sign-in', 'login', 'validation of credentials' → it's authentication.
Authentication verifies identity; authorisation grants permissions.
MFA is an authentication method, not an authorisation control.
Conditional Access is an authorisation engine that evaluates policies after authentication.
OpenID Connect is for authentication; OAuth 2.0 is for authorisation.
Access tokens default to 1 hour; refresh tokens to 90 days inactivity.
A user can be authenticated but denied access (authorisation failure).
Role-based access control (RBAC) is an authorisation model.
In Microsoft identity, authentication yields ID tokens; authorisation yields access tokens.
Kerberos is on-premises; OpenID Connect/OAuth are cloud protocols.
Token validation (signature, audience, expiry) is part of authorisation.
These come up on the exam all the time. Here's how to tell them apart.
Authentication
Verifies identity: 'Who are you?'
Uses credentials: password, MFA, biometrics
Results in a security token (ID token)
Protocols: OpenID Connect, SAML, Kerberos
Occurs before authorisation
Authorisation
Determines access: 'What can you do?'
Uses policies, roles, permissions
Results in access grant or denial (403)
Protocols: OAuth 2.0, RBAC, ABAC
Occurs after successful authentication
Mistake
MFA is an authorisation control.
Correct
MFA is an authentication enhancement that requires additional verification factors. Authorisation occurs after MFA and determines what resources the authenticated user can access.
Mistake
Conditional Access is part of the authentication process.
Correct
Conditional Access is an authorisation engine that evaluates policies after authentication. It can enforce MFA or block access, but it does not validate credentials.
Mistake
If a user is denied access, it is always an authentication failure.
Correct
Denial after successful login is typically an authorisation failure. The user is authenticated but lacks permissions.
Mistake
OAuth 2.0 is used for authentication.
Correct
OAuth 2.0 is an authorisation framework. OpenID Connect, built on OAuth 2.0, provides authentication.
Mistake
Kerberos is used in cloud-only environments.
Correct
Kerberos is primarily used in on-premises Active Directory. Azure AD uses OpenID Connect/OAuth 2.0 for authentication.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Authentication verifies who you are (e.g., by checking your password). Authorisation determines what you are allowed to do (e.g., read a file). In Microsoft, authentication uses OpenID Connect or SAML; authorisation uses OAuth 2.0 or RBAC. For the exam, remember that authentication happens first and results in a token; authorisation then uses that token to check permissions.
MFA is strictly authentication. It adds an extra layer of identity verification. Authorisation is separate and happens after MFA. For example, even with MFA, you might be denied access to a sensitive document if you lack the required role.
Azure AD uses OpenID Connect for modern authentication. It also supports SAML 2.0 for federation and WS-Federation for legacy apps. OpenID Connect returns an ID token (JWT) that contains claims about the user.
Azure AD uses OAuth 2.0 for authorisation. It returns an access token (JWT) with scopes or roles that the resource server uses to grant or deny access. OAuth 2.0 is not used for authentication; it is an authorisation framework.
The default access token lifetime is 1 hour (60 minutes). Refresh tokens default to 90 days without use. Session tokens (non-persistent) default to 8 hours. These can be configured via token lifetime policies.
Conditional Access is an authorisation control that runs after authentication. It evaluates signals like user location, device compliance, and sign-in risk to enforce policies (e.g., require MFA, block access). It is not authentication itself.
Yes, absolutely. Authentication only proves identity. Authorisation then checks permissions. For example, a user can log into Office 365 but cannot access the finance SharePoint site because they lack the 'Finance Members' role.
You've just covered Authentication vs Authorisation — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?