Study guide
5.2 Federated Access with OAuth2, SAML, and OpenID Connect
ISC2 Systems Security Certified Practitioner SSCP
Track your progress as you read
Finished sections get a check mark.
1 Introduction and Exam Overview
1.1 Current Exam Facts 1.2 Computerized Adaptive Testing, Scoring, and Retakes 1.3 Eligibility, Associate Pathway, Endorsement, and Maintenance
2 Ethics and Security Concepts
2.1 Comply with Codes of Ethics 2.2 Understand Security Concepts 2.3 Identify and Implement Security Controls
3 Functional Controls, Assets, and Change Management
3.1 Document and Maintain Functional Security Controls 3.2 Support and Implement the Asset Management Lifecycle 3.3 Support and Implement the Change Management Lifecycle
4 Security Awareness and Physical Security Operations
4.1 Support and Implement Security Awareness and Training 4.2 Collaborate with Physical Security Operations
5 Authentication Methods and Trust Architectures
5.1 Implement and Maintain Authentication Methods 5.2 Federated Access with OAuth2, SAML, and OpenID Connect 5.3 Understand and Support Internetwork Trust Architectures
6 Identity Lifecycle and Access Control Models
6.1 Support and Implement the Identity Management Lifecycle 6.2 Mandatory, Discretionary, and Role-Based Access Control 6.3 Rule-Based, Attribute-Based, and Privileged Access Management
7 Risk Management, Visibility, and Legal Concerns
7.1 Risk Management Concepts and Treatment 7.2 Risk Visibility, Reporting, and Threat Intelligence 7.3 Legal and Regulatory Concerns
8 Assessments, Monitoring, and Analysis
8.1 Security Assessments and Vulnerability Management 8.2 Operate and Monitor Security Platforms 8.3 Analyze Monitoring Results
9 Incident Response and Forensic Investigations
9.1 Incident Response: Preparation, Detection, Analysis, and Escalation 9.2 Containment, Eradication, Recovery, and Lessons Learned 9.3 Understand and Support Forensic Investigations
10 Business Continuity and Disaster Recovery
10.1 Business Continuity and Emergency Response 10.2 Disaster Recovery and Restoration Metrics 10.3 Backup, Redundancy, Testing, and Drills
11 Cryptography Foundations
11.1 Reasons and Requirements for Cryptography 11.2 Hashing, Salting, Symmetric, Asymmetric, and ECC 11.3 Digital Signatures, HMAC, Algorithm Strength, and Cryptanalysis
12 Secure Protocols and Public Key Infrastructure
12.1 Understand and Implement Secure Protocols 12.2 Understand Public Key Infrastructure
13 Networking Fundamentals, Attacks, and Access Controls
13.1 Understand and Apply Fundamental Concepts of Networking 13.2 Understand Network Attacks and Countermeasures 13.3 Manage Network Access Controls
14 Network Security Operations, Wireless, and IoT
14.1 Manage Network Security 14.2 Operate and Configure Network-Based Security Appliances and Services 14.3 Secure Wireless Communications 14.4 Secure and Monitor Internet of Things
15 Malware, Malicious Activity, and Endpoint Security
15.1 Identify and Analyze Malicious Code 15.2 Malicious Activity, Social Engineering, and Behavior Analytics 15.3 Implement and Operate Endpoint Device Security
16 Mobile, Cloud, and Virtual Environments
16.1 Administer and Manage Mobile Devices 16.2 Cloud Security: Deployment, Service Models, and Shared Responsibility 16.3 Cloud Legal, Regulatory, and Third-Party Requirements 16.4 Operate and Maintain Secure Virtual Environments
5.2 Federated Access with OAuth2, SAML, and OpenID Connect
Key Takeaways Explain This Topic AI
Open Authorization 2 (OAuth2) is an authorization and delegation protocol; OpenID Connect (OIDC) is an identity layer on OAuth2 that issues ID tokens; Security Assertion Markup Language (SAML) uses signed XML assertions for enterprise single sign-on.
The identity provider (IdP) authenticates the user and issues the token or assertion; the service provider (SP) or relying party (RP) consumes it and must not store the directory password.
Redirect Uniform Resource Identifiers on OAuth2/OIDC app registrations must be exact pre-registered values; wildcards and open redirects enable code or token theft.
Assertion replay is limited by short lifetimes, unique assertion IDs or one-time use, audience restriction, destination checks, and Hypertext Transfer Protocol Secure (HTTPS).
Joining a Software as a Service (SaaS) app with SAML is an operations task: metadata, Assertion Consumer Service URL, least-privilege claims, MFA at the IdP, and signing-certificate maintenance.
Last updated: August 2026
Federated access is how apps trust someone else's login
Knowledge area 2.1 also lists federated access , with Open Authorization 2 (OAuth2) and Security Assertion Markup Language (SAML) as the named examples. Federation means an application does not store the user's password. It trusts an identity provider (IdP) to authenticate the user and send a signed statement — a token or assertion — that the application, acting as a service provider (SP) or relying party (RP) , can verify.
You implement federation when you join a Software as a Service (SaaS) application, when you let a mobile app call an application programming interface (API) on a user's behalf, and when two companies share an extranet without copying accounts. You maintain it when token-signing certificates expire, when redirect Uniform Resource Identifiers ( URIs ) drift, and when a former employee still has a live session at the SaaS.
The SSCP trap is treating OAuth2, OpenID Connect (OIDC) , and SAML as synonyms. They are related, they are not the same protocol, and they fail in different ways.
Roles: identity provider versus service provider
Role Also called What it does Operations example
Identity provider IdP; authorization server in OAuth2; OpenID Provider Authenticates the user; issues tokens or SAML assertions Active Directory Federation Services, Entra ID, Okta
Service provider SP, relying party, client, resource server Consumes the assertion or token and creates a local session or API access Human-resources SaaS, ServiceNow, an internal API
User agent Browser or native app Carries redirects and form posts Browser, mobile app
The IdP holds the credentials and multi-factor authentication ( MFA ). The SP must not be given the directory password. If a vendor asks you to "sync passwords nightly," that is credential sharing, not federation. Federation is a signed statement plus a trust in the IdP's signing key.
OAuth2 is authorization and delegation
OAuth2 lets a user (resource owner) grant a client application limited access to a resource server without sharing a password . Classic picture: a calendaring app wants to read cloud mail. The user authenticates to the mail provider; the provider issues the calendaring app an access token scoped to mail.read , not to wipe the mailbox.
OAuth2 is not by itself an authentication protocol. It answers "what may this client do?" An access token is a capability — often a JSON Web Token (JWT) or an opaque handle. A refresh token lets the client obtain new access tokens without another interactive login. An authorization code is a short-lived code the client exchanges at the token endpoint. The authorization code flow with Proof Key for Code Exchange (PKCE) is the default for browser and mobile apps.
Grant types you will see on an operations shift:
Authorization code : interactive user, browser redirect.
Client credentials : daemon or service, no user — a machine identity.
Refresh token : silent renewal of access tokens.
Avoid or retire: implicit flow (tokens in the URL fragment) and resource-owner password credentials (the client sees the password).
Redirect URI registration is a hard control. The authorization server must send the code or token only to a pre-registered URI. If you allow a wildcard, or an open redirect such as https://app.example.com/callback?next= , an attacker can steal codes. Maintain the allowlist. Do not temporarily add http://localhost on a production app registration because a developer asked during a demo.
Scopes are least privilege for APIs. Mail.Read is not Directory.ReadWrite.All . An SSCP who rubber-stamps tenant-wide application permissions on a weekend integration has created a two-way trust with whoever later compromises that client secret.
OpenID Connect is the identity layer on OAuth2
OpenID Connect adds authentication on top of OAuth2. After the user signs in, the IdP issues an ID token — a signed JWT with identity claims ( sub , iss , aud , exp , often email and groups). The RP validates signature, issuer, audience, and expiry, then treats the user as authenticated.
Contrast that with raw OAuth2: an access token that can call an API does not, by itself, tell a client who the user is in a way the client should trust for login. OIDC exists so SSO and "Sign in with ..." buttons have a standard identity artifact. SSCP items that say "identity layer on OAuth2" want OIDC, not SAML and not bare OAuth2.
OIDC still uses OAuth2's redirect, authorization code, and token endpoints. One flow can return both an ID token (who) and an access token (what). Do not confuse them. Presenting an ID token to an API that expected an access token, or stuffing extra privileges into an ID token, is a design smell. Validate nonce on the ID token to bind it to the browser session that started the login, and reject tokens whose aud is some other application.
SAML: XML assertions and enterprise SSO
SAML 2.0 is the enterprise SSO workhorse, especially for older and many SaaS products. The IdP produces a signed XML assertion that states the subject, authentication context, conditions ( NotBefore , NotOnOrAfter , audience), and attributes (groups, employee number). The browser POSTs that assertion to the SP's Assertion Consumer Service (ACS) URL.
SAML is about authentication and attribute statements to an SP. It is not a general-purpose API authorization protocol. You typically use SAML to start a session; the SP then issues its own cookie. You do not staple a SAML assertion onto every Representational State Transfer call the way you send an OAuth2 bearer token.
Scenario: joining a SaaS application via SAML
A human-resources director buys a benefits SaaS. You, the SSCP practitioner, do not create a new password database. You:
Collect SP metadata: Entity ID, ACS URL, required NameID format (often email or a persistent opaque identifier), and which attributes the vendor actually needs.
Create a relying-party trust on ADFS, or an enterprise application on the cloud IdP. Upload the SP metadata. Return IdP metadata — Entity ID, SSO URL, token-signing certificate — to the vendor.
Map claims with least privilege: user.mail as NameID, department, groups. Do not send Social Security numbers in the assertion because a form field existed on the vendor's setup wizard.
Require MFA at the IdP. The SaaS should not become a second password prompt.
Pilot one user, then enforce. Document the ACS URL. A typo sends assertions into a void or, worse, toward a similar hostname an attacker registered.
Maintain the integration: signing-certificate rollover, leaver deprovisioning at the IdP (and System for Cross-domain Identity Management if the vendor supports it), and a vaulted break-glass local admin at the SaaS that is monitored — because when federation breaks, payroll still has to run.
That is federated access as an operations task, not a protocol religion. The diagram below is the happy path for that SAML join.
Loading diagram... SAML federation when joining a SaaS application
Tokens, assertion replay, and redirect traps
Artifact Typical format Primary job Replay and theft control
SAML assertion Signed XML Prove authentication to an SP Short NotOnOrAfter , unique ID, one-time use, Hypertext Transfer Protocol Secure (HTTPS) , audience and destination checks
OIDC ID token Signed JWT Prove identity to the RP exp / iat / nonce , audience equals this RP, signature against the IdP key
OAuth2 access token JWT or opaque Authorize API calls Short lifetime; sender-constrained tokens (mutual TLS or DPoP) where available
- Refresh token Opaque, high value Mint new access tokens Rotation, bind to client, revoke on leaver
- Authorization code Short string Exchange for tokens PKCE, exact redirect URI, one-time redeem
Assertion replay is the exam's favorite SAML failure. An attacker who captures a POST — compromised browser extension, leftover debug log, cleartext HTTP — resubmits the same assertion. If the SP does not check time windows, unique IDs, and audience, it opens a session for the attacker. The same idea applies to stolen authorization codes when redirect URIs are sloppy.
Validate, every time:
Signature against the IdP's published signing key, not a key the attacker embedded in the message.
Audience equals this SP, not any relying party in the metadata file.
Time conditions, with a small clock-skew allowance. Network Time Protocol on both IdP and SP matters here.
Destination / ACS matches the URL you configured.
InResponseTo matches the request you sent, for SP-initiated flows.
Clock skew is an operations outage as well as a security control. If the SP is five minutes fast, valid assertions look expired. If it is five minutes slow, a just-expired assertion still works — which is a replay window.
Choosing SAML, OIDC, or OAuth2
Use SAML when the SaaS only speaks SAML — still the majority of "enterprise SSO" checkboxes. Use OIDC when you need modern SSO, mobile apps, and single-page logins. Use OAuth2 (often with OIDC in front for the user) when an application needs delegated access to an API. Do not say "we use OAuth2" when you meant "log the user in"; that is OIDC. Do not put SAML on a machine-to-machine daemon; that is client-credentials OAuth2.
Federation does not replace device authentication or phishing-resistant MFA at the IdP. It concentrates them there. That is why the IdP, the token-signing certificate, and the app-registration portal are crown-jewel systems: compromise one, and every connected SaaS session is in play. Maintain federation the same way you maintain any authentication method — inventory of apps, certificate lifetime, redirect-URI reviews, and a leaver process that kills IdP sessions instead of hoping each SaaS noticed.