In today’s cloud-centric world, users rarely access applications that all belong to the same company. The core challenge is letting a user log in to one system (like Google) and gain instant, secure access to another system (like Salesforce) without re-entering credentials. This is the goal of Federated Identity.
Federated Identity is a crucial concept in SSCP Domain 2: Security Operations and Administration. It describes the administrative policy and technical protocols that allow one organization (the Identity Provider) to securely vouch for a user’s identity to another organization (the Service Provider). This seamless trust is built upon three foundational protocols: SAML, OAuth, and OpenID Connect.
The Core Concept: The Circle of Trust
At its heart, federation establishes a Circle of Trust between two key entities:
- Identity Provider (IdP): The system that holds the user’s primary credentials (e.g., your company’s Active Directory or Google). The IdP authenticates the user.
- Service Provider (SP) or Relying Party (RP): The application or website the user wants to access (e.g., a payroll system or a cloud storage service). The SP relies on the IdP’s authentication.
Once the IdP verifies the user, it passes an encrypted security token to the SP, proving the user’s identity and authorizing access.
1. SAML (Security Assertion Markup Language)
SAML is the oldest and most established standard for federation. It is primarily used in high-assurance, business-to-business (B2B) or enterprise environments for Single Sign-On (SSO).
- What it does (Authentication): SAML’s sole purpose is to securely convey authentication and authorization data (assertions) between the IdP and the SP. It’s an “all-or-nothing” approach: you are either logged in and granted access, or you are not.
- Token Format: SAML uses XML (eXtensible Markup Language) to structure its assertions.
- Key Characteristic: SAML is excellent for internal SSO and cloud services where the user is an employee. It is generally heavyweight and complex to implement, but robust.
Scenario: A company uses Microsoft Azure Active Directory (the IdP) to manage employee logins. When an employee tries to access an internal HR portal (the SP), Azure AD sends an XML SAML assertion proving the employee is legitimate, allowing the portal to grant access.
2. OAuth 2.0 (Open Authorization)
OAuth is fundamentally different from SAML. It is not an authentication protocol; it is an authorization protocol. It manages permission delegation and access control.
- What it does (Authorization): OAuth allows a user to grant a third-party application limited access to their resources on a service without sharing their primary password. The user delegates permission to the application.
- Token Format: OAuth uses simple, URL-friendly JSON Web Tokens (JWTs).
- Key Characteristic: OAuth is built for delegation. Think of it as a valet key—you give the valet limited permission (to drive the car) but not full access (to the trunk or glovebox).
Scenario: You log into Spotify (the Client) and want to find friends via Facebook (the Authorization Server). Spotify uses OAuth to ask Facebook for an Access Token. This token allows Spotify only to read your Friends List—it cannot change your password, post updates, or access your photos.
3. OpenID Connect (OIDC)
OpenID Connect (OIDC) is essentially an authentication layer built on top of OAuth 2.0. It combines the delegation power of OAuth with the authentication and identity verification capabilities required for user login.
- What it does (Authentication + Authorization): OIDC uses the OAuth framework to issue two main tokens:
- ID Token (Authentication): A JWT that proves who the user is (contains identity claims like name, email, and user ID).
- Access Token (Authorization): A separate token that grants permission to access specific resources (the OAuth part).
- Token Format: OIDC leverages the lightweight JSON Web Token (JWT) format, making it ideal for mobile applications, microservices, and modern web APIs.
- Key Characteristic: OIDC is the modern standard for consumer-facing identity (social logins) because it is simple, fast, and secure.
Scenario: You click “Log in with Google” on a new e-commerce site (the Relying Party). Google acts as the IdP and uses OIDC to send an ID Token to the site, which verifies your name and email address, completing the registration and login in one step.
Comparison of Key Protocols
| Protocol | Primary Purpose | Best Used For | Token Format | Complexity |
| SAML | Authentication | Enterprise SSO, B2B Trust, Compliance-heavy apps. | XML | High (Heavyweight) |
| OAuth 2.0 | Authorization | Permission Delegation, API Access (e.g., reading calendar data). | JWT | Moderate |
| OpenID Connect (OIDC) | Authentication + Authorization | Consumer-facing login (“Sign in with…”), Mobile/API applications. | JWT | Low (Lightweight) |
Resources for Further Study
These resources provide deeper, technical insights into how these protocols function at the application layer.
Extensive Website References
- OASIS Security Services Technical Committee (SAML)
- Reference: Search for “OASIS SAML 2.0 Specification”
- Value: Provides the core technical documentation detailing the structure of SAML assertions and bindings used in enterprise federation.
- IETF RFC 6749 (OAuth 2.0 Framework)
- Reference: Search for “IETF RFC 6749 OAuth 2.0”
- Value: The official engineering standard that defines the four roles and the various grant flows (e.g., Authorization Code, Implicit) that make up OAuth.
- OpenID Foundation (OpenID Connect)
- Reference: Search for “OpenID Connect Core Specification”
- Value: The primary source explaining how OIDC utilizes OAuth to add the crucial identity layer, specifically defining the ID Token and UserInfo endpoint.
Recommended Video Resources
| Focus Area | Recommended Video Search Topic | Key Takeaway |
| SAML vs. OIDC | “SAML vs OpenID Connect Explained” | A visual breakdown of the difference between the heavyweight enterprise XML-based approach and the modern, lightweight JSON approach. |
| OAuth Authorization Flow | “How OAuth 2.0 Works in 5 Minutes” | Demonstrates the key steps of the OAuth flow: the client requests access, the user approves, and the Authorization Server issues the token. |
| JSON Web Tokens (JWT) | “What is a JWT and How Does it Work” | Explains the structure (Header, Payload, Signature) and the cryptographic signing that makes JWTs a secure token format for OIDC and OAuth. |