Federation, SSO, SAML, OIDC, and OAuth
Key Takeaways
- Federation lets an identity provider assert identity information to a service provider in a different trust domain.
- SSO improves usability but concentrates risk, raising the importance of MFA, conditional access, and identity provider resilience.
- SAML is XML-based and dominant in browser-based enterprise SSO.
- OIDC adds an identity layer on top of OAuth 2.0 and issues an ID token (a JWT) for authentication.
- OAuth 2.0 handles delegated authorization with scoped access tokens and is not, by itself, proof that a user authenticated.
Federation and the Trust Chain
Federation lets a service provider (SP), also called a relying party (RP), trust identity information issued by an identity provider (IdP) in a separate administrative domain. The user authenticates once at the IdP, and the IdP sends a signed statement or token to the application. Single sign-on (SSO) is the user-facing result: one authentication experience that opens many applications.
Vocabulary
| Term | Plain-language meaning |
|---|---|
| Identity provider (IdP) | Authenticates the user and issues identity data |
| Service provider / relying party | Application that trusts the IdP |
| Federation | Trust relationship between identity domains |
| SSO | One authentication used across multiple apps |
| Assertion / token | Signed data carrying identity or authorization |
SAML vs OIDC vs OAuth
| Protocol | Primary purpose | Token format | Exam clue |
|---|---|---|---|
| SAML 2.0 | Enterprise web authentication (SSO) | XML assertion | "XML," "service provider," "identity provider," browser POST |
| OpenID Connect (OIDC) | Authentication for modern/mobile apps | ID token (JWT) | "ID token," "who the user is," built on OAuth 2.0 |
| OAuth 2.0 | Delegated authorization | Access token + scopes | "API access," "scopes," "consent," no password shared |
OAuth is the most-tested trap. OAuth lets a calendar app read a user's calendar via an access token with a defined scope, but a valid access token does not prove the human authenticated to your app. OIDC fixes this by riding on OAuth 2.0 flows and adding an ID token that asserts authentication. Memorize: SAML and OIDC = authentication; OAuth = authorization.
Scenario: SaaS SSO with SAML
A company uses a cloud IdP for SSO into a project-management SaaS app. The IdP requires MFA when the user is off the corporate network (a conditional access rule). The SaaS app trusts signed SAML assertions and maps the Project-Managers group to a project-administrator role.
Simplified sign-in chain:
2026-06-14T18:22:10Z idp event=auth user=lsantos mfa=success method=push risk=medium source_ip=198.51.100.24
2026-06-14T18:22:12Z idp event=saml_assertion app=project-saas user=lsantos groups=Project-Managers assertion_id=A-7719 result=issued
2026-06-14T18:22:13Z app event=sso_login user=lsantos mapped_role=project_admin result=success
Notice authentication happens at the IdP and authorization mapping happens at the SP. A SY0-701 question may ask which system decides the user's role; the answer is the SP's group-to-role mapping, not the IdP.
Token and Trust Risks
Federation kills password sprawl but concentrates risk at the IdP. If an attacker steals a session or refresh token, abuses an OAuth consent grant, swaps a signing certificate, or bypasses MFA, every connected app is exposed. The infamous Golden SAML attack forges assertions after stealing the IdP signing key.
Key controls:
- MFA and conditional access (device, location, risk).
- Signing-certificate rotation and strict assertion validation.
- Short token lifetimes and refresh-token rotation/revocation.
- App consent governance to block risky OAuth apps.
- Monitoring for impossible travel, unusual consent, and token replay.
Common Traps
- Calling OAuth an authentication protocol without OIDC.
- Assuming SSO automatically enforces least privilege.
- Ignoring role mapping inside the service provider.
- Failing to revoke active sessions and refresh tokens after disabling an account.
- Trusting an unsigned or improperly validated token.
Exam Focus
For SSO into a SaaS app, pick SAML (enterprise/XML) or OIDC (modern/ID token). For a third-party app needing limited API access without the user's password, pick OAuth delegated authorization. To reduce SSO risk, pick MFA, conditional access, token controls, and monitoring.
How the Protocols Move Tokens
Understanding the flow helps you eliminate wrong answers. In a SAML flow the browser is the courier: the IdP signs an XML assertion and the browser POSTs it to the SP. In an OIDC flow the app exchanges an authorization code for an ID token plus an access token at the IdP's token endpoint. In raw OAuth 2.0 the resource owner consents, the client receives a scoped access token, and that token is presented to the resource server (an API). If an exam stem mentions XML and browser redirects, think SAML; if it mentions a JWT ID token, think OIDC; if it mentions scopes and an API, think OAuth.
On-Premises Federation Building Blocks
SY0-701 still tests older identity plumbing. LDAP (Lightweight Directory Access Protocol) queries the directory and should run over TLS (LDAPS) to avoid exposing credentials. Kerberos provides ticket-based SSO inside a Windows domain using a Key Distribution Center and time-sensitive tickets, which is why clock skew beyond about five minutes breaks authentication. RADIUS and TACACS+ centralize authentication for network devices and VPNs; TACACS+ encrypts the full payload and separates authentication, authorization, and accounting, while RADIUS encrypts only the password.
Real-World Failure Modes
| Failure | Consequence | Control |
|---|---|---|
| Expired SP signing certificate | Assertions rejected, mass lockout | Certificate lifecycle monitoring |
| Over-broad OAuth scope | App reads more than intended | Least-privilege scope + consent review |
| Long-lived refresh token | Stolen token = lasting access | Short lifetimes + revocation on disable |
| No SP-side role mapping | All federated users over-privileged | Group-to-role mapping + least privilege |
These pairings are common single-best-answer targets: match the symptom to the precise control rather than reaching for a generic "add MFA" response when the stem describes a certificate or scope problem.
A web application needs to authenticate users through a modern identity provider and receive an ID token. Which protocol is the best fit?
A third-party reporting tool needs permission to read a user account through an API without receiving the user password. Which concept is most relevant?
What is a key operational risk of single sign-on?