This chapter covers Single Sign-On (SSO), Security Assertion Markup Language (SAML), and OAuth 2.0—three interrelated but distinct technologies that manage authentication and authorization in modern enterprise environments. For SY0-701 Objective 1.2 (General Security Concepts), you must understand how these protocols enable secure, federated identity management while avoiding common implementation pitfalls. We'll dissect each protocol's mechanism, compare their use cases, and highlight exactly what the exam tests—including the critical differences between authentication and authorization delegation.
Jump to a section
Imagine a large music festival with multiple stages, VIP areas, and merchandise booths. Instead of buying separate tickets for each attraction, you get a single wristband (the SSO token) at the main entrance. This wristband contains an embedded chip that stores your identity and permissions. When you approach the VIP lounge, you tap your wristband against a reader (the service provider). The reader doesn't know you personally; it simply sends a query to the central festival database (the identity provider) asking, 'Does this wristband belong to someone authorized for VIP?' The database checks its records and returns a simple yes or no, along with any relevant attributes (e.g., age for alcohol access). This mechanism mirrors SAML: the wristband is the SAML assertion, the reader is the service provider, and the central database is the identity provider. The key is that the wristband itself does not contain your personal data—only a reference ID. The actual identity verification happens behind the scenes. If someone tries to counterfeit a wristband, the central database can revoke it instantly, preventing unauthorized access across all venues. This is exactly how SSO centralizes authentication: one credential, many services, and the token is just a pointer to a centrally managed identity.
What is SSO?
Single Sign-On (SSO) is an authentication process that allows a user to access multiple applications or services with one set of login credentials. The core idea is that after a single successful authentication at a central identity provider (IdP), the user is automatically authenticated to all other relying services (service providers, or SPs) without re-entering credentials. SSO reduces password fatigue, decreases help desk calls for password resets, and centralizes access control. However, it also introduces a single point of failure: if the IdP is compromised, all connected services are at risk.
How SSO Works Mechanically
The SSO process typically involves these steps: 1. User attempts to access a service (e.g., a cloud application). 2. The service redirects the user to the IdP for authentication. 3. The user provides credentials (e.g., username/password, smart card, biometric). 4. The IdP validates credentials and creates an authentication token (e.g., a SAML assertion or a Kerberos ticket). 5. The IdP redirects the user back to the service with the token. 6. The service validates the token (often by checking a digital signature or querying the IdP) and grants access.
SAML – Security Assertion Markup Language
SAML (pronounced "sam-ell") is an XML-based open standard for exchanging authentication and authorization data between an IdP and an SP. The most common version is SAML 2.0, defined by OASIS. SAML is primarily used for federated identity—allowing users to log into one domain and access resources in another domain (e.g., logging into a corporate portal and then accessing a partner's SaaS application).
SAML Components: - Identity Provider (IdP): Authenticates the user and issues SAML assertions. - Service Provider (SP): Consumes the SAML assertion to grant access to its resources. - Subject: The user or entity being authenticated. - Assertion: The XML payload containing authentication statements, attribute statements, or authorization decision statements. - Protocol Binding: Defines how SAML messages are transported (e.g., HTTP Redirect, HTTP POST, Artifact Resolution).
SAML Flow (SP-initiated SSO): 1. User requests a resource from SP (e.g., https://app.example.com/resource). 2. SP determines user is not authenticated and generates a SAML authentication request. 3. SP redirects user to IdP's SSO service URL with the request (via HTTP Redirect or POST). 4. IdP authenticates the user (e.g., via password, multi-factor). 5. IdP creates a SAML assertion containing the user's identity and optionally attributes (like role or email). The assertion is digitally signed with the IdP's private key (using RSA-SHA256, for example). 6. IdP sends the assertion back to SP via the user's browser (HTTP POST to SP's Assertion Consumer Service URL). 7. SP validates the assertion signature using the IdP's public key (pre-shared or from metadata). If valid, SP establishes a session for the user and grants access.
SAML Security Considerations: - Assertions must be signed to prevent tampering. Encryption is optional (using XML Encryption) for sensitive attributes. - The IdP and SP exchange metadata (XML documents) containing endpoints, certificates, and supported bindings. - Common attacks: XML Signature Wrapping, replay attacks (mitigated by including timestamps and unique IDs), and man-in-the-middle if TLS is not enforced. - CVE example: CVE-2018-0489 in XML Security Library allowed signature bypass due to improper canonicalization.
OAuth 2.0 – Delegated Authorization
OAuth 2.0 (RFC 6749) is an authorization framework that enables a third-party application to obtain limited access to a resource server on behalf of a resource owner (user), without revealing the user's credentials. OAuth 2.0 is not an authentication protocol—it does not verify the user's identity; it grants access tokens. However, it is often used in conjunction with OpenID Connect (OIDC) for authentication.
OAuth 2.0 Roles: - Resource Owner: The user who owns the data (e.g., a Facebook user). - Client: The application requesting access (e.g., a third-party quiz app). - Authorization Server: Issues access tokens after authenticating the resource owner. - Resource Server: Hosts the protected resources (e.g., Facebook's API).
OAuth 2.0 Grant Types (Flows): 1. Authorization Code Grant: The most common. Client redirects user to authorization server, user authenticates and approves, server returns an authorization code (not the token) to the client via redirect URI. Client then exchanges the code (plus client secret) for an access token. This adds security because the token is never exposed to the user agent. 2. Implicit Grant (deprecated in OAuth 2.1): The access token is returned directly in the redirect URI. Vulnerable to token leakage. Used for public clients (e.g., single-page apps). 3. Resource Owner Password Credentials Grant: User provides username/password directly to the client, which sends them to the authorization server. Only used when highly trusted. 4. Client Credentials Grant: Client authenticates itself (not a user) to get an access token for its own resources. 5. Device Code Grant: For devices with limited input (e.g., smart TVs). User visits a URL on another device to approve.
OAuth 2.0 Flow (Authorization Code with PKCE): 1. Client generates a cryptographic challenge (code_verifier and code_challenge). 2. Client redirects user to authorization server with the challenge, client ID, redirect URI, and scope. 3. User authenticates and approves the request. 4. Authorization server redirects back to client with an authorization code. 5. Client sends the code, code_verifier, and client secret (if confidential) to the token endpoint. 6. Authorization server verifies the code_verifier against the challenge, issues an access token (and optionally a refresh token). 7. Client uses the access token to call the resource server API.
Security Considerations: - Access tokens are typically JSON Web Tokens (JWT) or opaque strings. They should be short-lived (e.g., 1 hour). - Refresh tokens allow obtaining new access tokens without user interaction; they must be stored securely. - CSRF attacks are mitigated by using state parameter. - Redirect URI validation is critical to prevent authorization code interception (CVE-2017-5638 in Apache Struts2 related to OAuth). - PKCE (Proof Key for Code Exchange, RFC 7636) prevents authorization code interception on public clients.
Comparing SAML and OAuth 2.0
Purpose: SAML is for authentication (federated identity); OAuth 2.0 is for delegated authorization. However, SAML can carry authorization attributes, and OAuth 2.0 can be extended with OIDC for authentication.
Message Format: SAML uses XML; OAuth 2.0 uses JSON (for tokens and responses).
Token Type: SAML assertions are XML; OAuth 2.0 uses access tokens (often JWTs).
Use Cases: SAML is common in enterprise SSO (e.g., ADFS, Okta); OAuth 2.0 is used for API access (e.g., Facebook Login, Google APIs).
Transport: Both rely on TLS for transport security.
OpenID Connect (OIDC)
OIDC is an authentication layer built on top of OAuth 2.0. It adds an ID token (a JWT) that contains user identity claims. OIDC is the modern approach for SSO in web and mobile applications, often replacing SAML. For SY0-701, know that OIDC provides authentication while OAuth 2.0 provides authorization.
Command/Tool Examples
- SAML debugging: Use curl to inspect SAML responses (though they are XML, often base64-encoded).
- JWT inspection: jq tool can parse JWTs. Example:
echo "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.EkN-DOsnsuRjRO6BxXemm1mHqOc" | jq -R 'split(".") | .[0],.[1] | @base64d | fromjson'- OAuth 2.0 token request with curl:
curl -X POST https://auth.example.com/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=authorization_code&code=AUTH_CODE&redirect_uri=https://client.example.com/callback&client_id=CLIENT_ID&client_secret=CLIENT_SECRET"How Attackers Exploit SSO/OAuth
Token theft: If an access token is intercepted (e.g., via XSS or insecure storage), an attacker can impersonate the user until the token expires.
CSRF in OAuth: Without the state parameter, an attacker can trick a user into linking their account to the attacker's client.
SAML replay: If assertions lack unique IDs or timestamps, an attacker can reuse a captured assertion.
Misconfigured redirect URIs: In OAuth, an open redirector can leak authorization codes to attacker-controlled servers.
Weak signature algorithms: SAML assertions signed with SHA-1 are vulnerable to collision attacks (CVE-2017-9805).
Defensive Measures
Always use TLS (HTTPS) for all endpoints.
Validate redirect URIs strictly (exact match, not prefix).
Use PKCE for public OAuth clients.
For SAML, enforce assertion signing, validate timestamps, and use unique assertion IDs.
Implement short token lifetimes and refresh token rotation.
Monitor for anomalies: multiple token requests, unusual redirect patterns.
SAML SP-Initiated SSO Flow
Step 1: User requests a protected resource from the Service Provider (SP). The SP checks the user's session; if none exists, it generates a SAML authentication request (an XML document) and redirects the user to the Identity Provider's (IdP) Single Sign-On Service URL. The request is typically base64-encoded and sent via HTTP Redirect binding. Step 2: The IdP receives the request and authenticates the user—this could involve password, MFA, or certificate-based authentication. If the user already has a session at the IdP, this step is skipped. Step 3: After authentication, the IdP constructs a SAML assertion containing the user's identity (e.g., email, username) and optionally attributes (e.g., role, group). The assertion is digitally signed using the IdP's private key. Step 4: The IdP sends the assertion to the SP via the user's browser using HTTP POST binding (the assertion is placed in a hidden form field). Step 5: The SP validates the assertion signature using the IdP's public key (obtained from metadata). It also checks timestamps and the unique ID to prevent replay. If valid, the SP creates a local session and grants access.
OAuth 2.0 Authorization Code Flow
Step 1: The client application (e.g., a mobile app) initiates the flow by redirecting the user to the authorization server's authorization endpoint. The request includes client_id, redirect_uri, response_type=code, scope, and state (a CSRF token). Step 2: The user authenticates with the authorization server (e.g., via username/password) and approves the requested permissions (scope). Step 3: The authorization server redirects the user back to the client's redirect URI with an authorization code and the state parameter. Step 4: The client sends a POST request to the token endpoint with the authorization code, client_id, client_secret (if confidential), redirect_uri, and grant_type=authorization_code. Step 5: The authorization server validates the code and client credentials, then returns an access token (and optionally a refresh token) in JSON format. Step 6: The client uses the access token to call the resource server's API (e.g., GET /userinfo with Authorization: Bearer <token>). The resource server validates the token (by checking signature or introspecting with the authorization server) and returns the requested data.
OAuth 2.0 Token Refresh Flow
Step 1: The client detects that the access token is expired or about to expire (e.g., a 401 response from the resource server). Step 2: The client sends a POST request to the token endpoint with grant_type=refresh_token, refresh_token, and client credentials (client_id and secret, or client authentication). Step 3: The authorization server validates the refresh token (checks its authenticity, expiration, and revocation status). If valid, it issues a new access token (and optionally a new refresh token). Step 4: The client stores the new tokens (and discards the old ones if rotation is implemented). Step 5: The client retries the original request with the new access token. This flow allows long-lived sessions without requiring the user to re-authenticate.
OpenID Connect Authentication Flow
Step 1: The client sends an authentication request to the OpenID Provider (OP) with scope=openid (plus other scopes like profile, email) and response_type=code (or id_token token). Step 2: The OP authenticates the user and obtains consent. Step 3: The OP returns an authorization code (if using code flow) or directly an ID token (if using implicit flow). Step 4: If code flow, the client exchanges the code for an ID token and access token at the token endpoint. Step 5: The client validates the ID token (a JWT) by checking its signature (using the OP's public key), issuer, audience, and expiration. The ID token contains claims like sub (subject), name, email, and nonce (to prevent replay). Step 6: The client can optionally use the access token to call the UserInfo endpoint to get additional claims. This flow provides authentication (who the user is) on top of OAuth 2.0 authorization.
SAML Assertion Replay Attack
Step 1: Attacker intercepts a valid SAML assertion (e.g., by capturing network traffic or exploiting a XSS vulnerability). Step 2: Attacker extracts the SAML response XML (base64-decoded). Step 3: Attacker crafts a new HTTP request to the SP's Assertion Consumer Service (ACS) URL, submitting the intercepted assertion (e.g., via a form POST). Step 4: The SP receives the assertion, validates the digital signature (which is still valid because it was signed by the legitimate IdP). However, if the assertion lacks a unique ID or the SP does not check timestamps, the SP may accept it and create a session for the attacker as the original user. Step 5: The attacker now has access to the user's resources. Defenses: ensure assertions include a unique ID (e.g., UUID) and a timestamp with a short validity window (e.g., 5 minutes). Also, the SP should maintain a cache of consumed assertion IDs to prevent reuse.
Scenario 1: Enterprise SSO with SAML (ADFS) A healthcare organization uses Active Directory Federation Services (ADFS) as the IdP to provide SSO for multiple cloud applications (e.g., Office 365, Salesforce, custom EHR). An analyst notices that users are reporting intermittent access failures to Salesforce. The analyst checks the ADFS event logs (Event ID 1202 for successful logins, 364 for failures). They see that SAML assertions are being issued but Salesforce is rejecting them. Further investigation reveals that the clock on the ADFS server is skewed by 10 minutes, causing the assertion's NotBefore and NotOnOrAfter timestamps to be invalid. The correct response is to synchronize the server's time with an NTP source. A common mistake is to disable timestamp validation on the SP side, which opens up replay attacks. The analyst should also check the signature algorithm: Salesforce might require SHA-256, but ADFS was configured with SHA-1.
Scenario 2: OAuth 2.0 Token Theft via XSS A social media platform allows third-party apps via OAuth 2.0. A user's browser is infected with a malicious script that steals the access token from local storage (where the client app stored it). The attacker then uses the token to call the platform's API to read private messages. The SOC analyst sees anomalous API calls from an IP not associated with the user's typical location. Using a tool like Splunk, they query logs for the user's account and see multiple GET requests to /api/messages with the same token. The correct response is to revoke the token (via the authorization server's revocation endpoint) and force the user to re-authenticate. The analyst should also advise the client app to use short-lived tokens and store them in HTTP-only cookies instead of localStorage. A common mistake is to assume the token is safe because it's encrypted; but if the attacker has access to the client-side, they can still use it.
Scenario 3: OAuth Misconfiguration – Open Redirect A developer configures an OAuth client with a redirect URI pattern like 'https://client.example.com/*'. An attacker crafts a link that redirects to 'https://client.example.com/evil?code=AUTH_CODE' but the evil part is actually a redirect to attacker.com. The authorization server, seeing the pattern match, sends the authorization code to the attacker's server. The analyst, reviewing logs, sees multiple authorization code grants from the same IP to the same client but with different redirect URIs. The correct response is to change the redirect URI to an exact match (e.g., 'https://client.example.com/callback') and reject any variation. A common mistake is to allow wildcards for convenience, which directly enables this attack.
What SY0-701 Tests on This Objective: Objective 1.2 (General Security Concepts) expects you to understand the differences between authentication and authorization, and to identify the appropriate protocol for a given scenario. Specifically:
Recognize that SAML is used for federated identity and SSO across organizations (e.g., logging into a partner's website).
Understand that OAuth 2.0 is for delegated authorization (e.g., giving a third-party app access to your Google Drive).
Know that OpenID Connect (OIDC) adds authentication to OAuth 2.0.
Identify common SSO implementations like Active Directory Federation Services (ADFS), Okta, and Ping Identity.
Be aware of security concerns: token theft, replay attacks, CSRF, and open redirects.
Common Wrong Answers and Why Candidates Choose Them: 1. "SAML is used for API authorization" – Candidates confuse SAML's assertion capabilities with OAuth's token-based API access. SAML is for browser-based SSO, not direct API calls. 2. "OAuth 2.0 provides authentication" – OAuth 2.0 is authorization only. Without OIDC, it does not verify user identity. Candidates see 'login with Facebook' and assume OAuth authenticates, but it actually authorizes the app to access the user's profile data. 3. "SSO eliminates all password risks" – SSO centralizes authentication but doesn't eliminate password risks; it creates a single point of failure. If the IdP is compromised, all services are vulnerable. 4. "SAML and OAuth are interchangeable" – They serve different purposes. Candidates often pick SAML for mobile apps or OAuth for enterprise SSO, but the correct choice depends on the use case.
Specific Terms, Values, and Acronyms: - SAML 2.0, XML, assertion, IdP, SP, ADFS - OAuth 2.0, grant types (authorization code, implicit, client credentials, device code), access token, refresh token, scope, PKCE - OpenID Connect, ID token, JWT, sub claim, nonce - Ports: HTTPS (443) for all flows; no specific port for SAML or OAuth.
Common Trick Questions: - A scenario describes a user logging into a website using their Google credentials. The question asks 'What protocol is being used?' The answer is OpenID Connect (if authentication) or OAuth 2.0 (if authorization). Many candidates answer SAML because it's SSO, but Google uses OIDC/OAuth, not SAML. - A question about 'federated identity' often points to SAML, but remember that OIDC also provides federation. Look for clues like 'cross-domain authentication' vs. 'API access'.
Decision Rule for Eliminating Wrong Answers: If the scenario involves a user authenticating to a third-party service using their existing credentials (e.g., corporate login), it's likely SAML. If the scenario involves a third-party app accessing user data (e.g., reading emails), it's OAuth 2.0. If the scenario mentions 'ID token' or 'identity claims', it's OpenID Connect. Remember: SAML = authentication assertion (XML), OAuth = access token (JSON), OIDC = ID token (JWT).
SAML 2.0 is an XML-based standard for federated authentication and SSO, using an IdP and SP model.
OAuth 2.0 is a delegation protocol for authorization; it issues access tokens (often JWTs) to clients.
OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0, adding an ID token with user identity claims.
The Authorization Code Grant is the most secure OAuth 2.0 flow; always use PKCE for public clients.
SAML assertions must be signed (e.g., RSA-SHA256) and include timestamps and unique IDs to prevent replay.
OAuth 2.0 tokens should be short-lived (e.g., 1 hour) and stored securely (HTTP-only cookies for web apps).
Common attacks: token theft, CSRF (mitigated by state parameter), open redirects (mitigated by exact redirect URI validation), and SAML replay (mitigated by unique IDs and timestamps).
For SY0-701, remember: SAML = authentication (XML), OAuth = authorization (JSON), OIDC = authentication + authorization (JWT).
Federated identity allows users to authenticate across different organizations using a trusted IdP.
SSO creates a single point of failure; compromise of the IdP compromises all connected services.
These come up on the exam all the time. Here's how to tell them apart.
SAML 2.0
Uses XML for assertions and messages.
Primarily designed for enterprise federated SSO (e.g., ADFS).
Relies on browser redirects and POST bindings; not ideal for APIs.
Provides authentication and can carry authorization attributes.
Token format: SAML assertion (XML, often base64-encoded).
OpenID Connect (OIDC)
Uses JSON for tokens (JWT) and RESTful endpoints.
Designed for modern web and mobile apps (e.g., Google, Facebook).
Built on OAuth 2.0; uses token endpoint and API calls.
Provides authentication via ID token; authorization via access token.
Token format: JWT (JSON Web Token) for ID token; access token can be JWT or opaque.
OAuth 2.0 Authorization Code Grant
Returns an authorization code, not the token, in the redirect URI.
Requires a back-channel exchange (client to token endpoint) for the token.
More secure; token never exposed to user agent.
Supports PKCE for public clients.
Recommended for all client types (confidential and public).
OAuth 2.0 Implicit Grant (deprecated)
Returns the access token directly in the redirect URI fragment.
No back-channel; token is exposed to the browser and potentially to history.
Less secure; vulnerable to token leakage.
Cannot use PKCE effectively (no code exchange).
Deprecated in OAuth 2.1 due to security concerns.
Mistake
SAML and OAuth 2.0 are both authentication protocols.
Correct
SAML is primarily for authentication (federated identity). OAuth 2.0 is for authorization; it does not authenticate the user. OpenID Connect adds authentication on top of OAuth 2.0.
Mistake
SSO means you never need to enter a password again.
Correct
SSO reduces the number of logins but typically requires initial authentication with the identity provider. Passwordless SSO exists (e.g., using certificates or biometrics), but most implementations still use passwords as one factor.
Mistake
OAuth 2.0 tokens are always JWTs.
Correct
OAuth 2.0 does not mandate token format. Access tokens can be opaque strings (e.g., random UUIDs) that are validated by introspection. JWTs are common but not required.
Mistake
SAML is outdated and no longer used.
Correct
SAML 2.0 is still widely used in enterprise environments, especially for on-premises IdPs like ADFS and Shibboleth. It is not outdated; it coexists with OIDC.
Mistake
PKCE is only needed for mobile apps.
Correct
PKCE (Proof Key for Code Exchange) is recommended for all public clients, including single-page applications (SPAs) and mobile apps. It prevents authorization code interception even when the client secret cannot be kept confidential.
SAML is an authentication protocol that uses XML assertions to enable federated SSO across domains. OAuth 2.0 is an authorization protocol that uses JSON tokens to grant third-party apps limited access to user resources without sharing credentials. SAML focuses on who the user is (authentication), while OAuth focuses on what an app can do (authorization). For SY0-701, remember that SAML is for enterprise SSO (e.g., logging into a partner portal), and OAuth is for API access (e.g., a photo app accessing your Google Photos).
OAuth 2.0 is secure when implemented correctly. Key security measures include: using TLS for all endpoints, validating redirect URIs exactly, using the Authorization Code Grant with PKCE for public clients, storing tokens securely (e.g., HTTP-only cookies), and using short-lived access tokens. Common vulnerabilities arise from misconfigurations like open redirects, lack of state parameter (CSRF), or storing tokens in insecure locations (e.g., localStorage). The exam expects you to identify these misconfigurations.
The Identity Provider (IdP) authenticates the user and issues a SAML assertion that contains the user's identity and optionally attributes. The IdP is responsible for verifying credentials, managing sessions, and signing assertions. Examples include ADFS, Okta, and Ping Identity. The Service Provider (SP) trusts the IdP's assertion to grant access. If the IdP is compromised, all SPs that rely on it are at risk.
PKCE (Proof Key for Code Exchange, RFC 7636) is an extension to OAuth 2.0's Authorization Code Grant that prevents authorization code interception attacks. It is used primarily by public clients (e.g., mobile apps, SPAs) that cannot keep a client secret confidential. The client generates a cryptographic challenge (code_verifier) and sends a hashed version (code_challenge) in the initial request. When exchanging the code, the client sends the original verifier, which the authorization server matches. This ensures that even if the code is intercepted, the attacker cannot exchange it without the verifier.
No, OAuth 2.0 alone is not an authentication protocol. It only provides authorization (access to resources). To authenticate a user, you need OpenID Connect (OIDC), which adds an ID token containing user identity claims. Many services use 'Login with Facebook' which is actually OAuth 2.0 + OIDC. The exam may test this distinction: OAuth = authorization, OIDC = authentication.
A replay attack occurs when an attacker captures a valid SAML assertion and resubmits it to the SP to gain unauthorized access. Defenses include: including a unique assertion ID (e.g., UUID), embedding a timestamp with short validity (e.g., 5 minutes), and having the SP track used assertion IDs. The SP should reject assertions with expired timestamps or duplicate IDs. The exam may present a scenario where an SP does not check these fields, making it vulnerable to replay.
Federated identity is a broader concept where multiple organizations (or domains) agree to trust each other's identity assertions, enabling users to access resources across domains. SSO is a specific implementation where a user logs in once and gains access to multiple applications within a trusted environment. Federated identity often uses SSO (e.g., SAML-based federation). For the exam, understand that federated identity involves trust relationships between IdPs and SPs across different security domains.
You've just covered SSO, SAML, and OAuth 2.0 — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?