Principles of Information Security: Identity Federation and SSO (SAML, OAuth, OpenID Connect)

Identity Federation and SSO (SAML, OAuth, OpenID Connect)

Identity Federation & SSO (SAML, OAuth, OpenID Connect) – Exam-Ready Study Guide

What This Is

Identity Federation allows users to access multiple applications/services using a single set of credentials (e.g., logging into Gmail, YouTube, and Google Drive with one Google account). Single Sign-On (SSO) is a subset of federation that enables users to authenticate once and access multiple services without re-entering credentials. These technologies reduce password fatigue, improve security (fewer credentials to steal), and streamline user experience.

Why it’s critical:
- Security: Reduces attack surface by minimizing password reuse (a leading cause of breaches, e.g., the 2020 Twitter hack where attackers phished employee credentials to hijack high-profile accounts).
- Compliance: Meets regulatory requirements (e.g., NIST SP 800-63B, GDPR) for secure authentication.
- Operational efficiency: Eliminates helpdesk tickets for password resets (40% of helpdesk calls, per Gartner).

Real-world incident:
In 2017, OneLogin (an SSO provider) suffered a breach where attackers accessed a set of AWS keys, allowing them to decrypt sensitive data, including customer credentials. The attack exploited a misconfigured SAML implementation, highlighting the risks of improper federation setups.

Key Terms & Concepts

• Identity Provider (IdP):
  A trusted service that authenticates users and issues identity assertions (e.g., Okta, Microsoft Azure AD, Google Identity Platform). Follows standards like SAML 2.0 or OpenID Connect (OIDC).

• Service Provider (SP) / Relying Party (RP):
  The application or service a user wants to access (e.g., Salesforce, Slack). The SP/RP trusts the IdP to verify the user’s identity.

• SAML (Security Assertion Markup Language):
  An XML-based standard for exchanging authentication and authorization data between IdPs and SPs. Used in enterprise SSO (e.g., corporate logins to cloud apps). Port: Typically 443 (HTTPS).

• SAML Assertion: A signed XML document from the IdP containing user identity and attributes (e.g., "Alice is an admin").

• SAML Flow: SP-initiated (user clicks "Login with SSO") or IdP-initiated (user logs into IdP first, then accesses SP).

• OAuth 2.0 (Open Authorization):
  A delegation protocol that allows third-party apps to access resources on behalf of a user without sharing credentials (e.g., "Log in with Google" to grant a mobile app access to your contacts). Not an authentication protocol—it’s for authorization (e.g., "Can this app read my emails?").

• Roles:
  • Resource Owner (User): The person granting access (e.g., you).
  • Client (App): The third-party app requesting access (e.g., a fitness app).
  • Authorization Server (IdP): Issues access tokens (e.g., Google’s OAuth server).
  • Resource Server: Hosts protected data (e.g., Gmail API).
• Tokens:
  • Access Token: Short-lived (e.g., 1 hour) token granting access to resources.
  • Refresh Token: Long-lived token used to obtain new access tokens (stored securely).

• Grant Types (Flows):

  
  
  • Authorization Code: Most secure (used for web apps). User is redirected to IdP, which returns a code to the app. The app exchanges the code for tokens.
  • Implicit: Deprecated (used for single-page apps). Tokens returned directly in the URL (insecure).
  • Client Credentials: For machine-to-machine (M2M) communication (no user involved).
  • Password: User shares credentials directly with the app (avoid—defeats OAuth’s purpose).

• OpenID Connect (OIDC):
  An authentication layer built on OAuth 2.0 that adds identity verification (e.g., "Is this user really Alice?"). Uses JSON Web Tokens (JWT) instead of XML (like SAML).

• ID Token: A JWT containing user identity claims (e.g., sub = user ID, email = [email protected]).
• Flows: Same as OAuth 2.0, but with added identity verification.

• Example: Logging into Spotify with your Google account.

• JSON Web Token (JWT):
  A compact, URL-safe token format (e.g., header.payload.signature) used in OIDC and OAuth. Contains:

• Header: Token type (JWT) and algorithm (HS256, RS256).
• Payload: Claims (user data, expiration time).
• Signature: Ensures token integrity (prevents tampering).

• ⚠️ Risk: JWTs are base64-encoded, not encrypted by default. Always use HTTPS and validate signatures!

• Federation Metadata:
  XML (SAML) or JSON (OIDC) files that define trust relationships between IdPs and SPs (e.g., SAML’s metadata.xml or OIDC’s /.well-known/openid-configuration).

• Just-In-Time (JIT) Provisioning:
  Automatically creates user accounts in an SP when a user logs in for the first time via federation (e.g., a new employee logs into Salesforce via Azure AD).

• SCIM (System for Cross-domain Identity Management):
  A standard for automating user provisioning/deprovisioning across systems (e.g., when an employee is hired/fired, SCIM syncs their access across apps).

• LDAP (Lightweight Directory Access Protocol):
  A protocol for querying and modifying directory services (e.g., Active Directory). Often used by IdPs to store user data. Ports: 389 (unencrypted), 636 (LDAPS, encrypted).

• Multi-Factor Authentication (MFA) in Federation:
  IdPs can enforce MFA (e.g., SMS, TOTP, FIDO2) before issuing tokens/assertions. Critical for security—federation without MFA is a major risk (e.g., the 2020 Twitter breach).

Step-by-Step / Process Flow

1. Planning Federation (CISSP/Security+ Perspective)

• Assess requirements: Determine if SSO is needed (e.g., cloud apps, internal tools) and which standard to use (SAML for enterprise, OIDC for consumer apps).
• Choose an IdP: Evaluate options (e.g., Azure AD, Okta, Ping Identity) based on cost, compliance (e.g., FedRAMP), and features (MFA, SCIM).
• Define trust relationships: Identify SPs (e.g., Salesforce, Zoom) and configure metadata exchange (SAML/OIDC).

2. Configuring SAML Federation (Technical Steps)

1. Set up the IdP:
2. Register the SP in the IdP (e.g., in Azure AD, add a "Non-gallery application").
3. Upload the SP’s SAML metadata (or manually enter EntityID, ACS URL, Logout URL).
4. Set up the SP:
5. Configure the IdP’s SAML metadata in the SP (e.g., in Salesforce, go to Setup > Identity > Identity Provider).
6. Define attribute mappings (e.g., map email from IdP to username in SP).
7. Test the flow:
8. Initiate login from the SP (e.g., click "Login with SSO").
9. Verify the SAML assertion is signed and contains correct attributes.
10. Enable MFA (if required):
11. Configure MFA in the IdP (e.g., Azure AD Conditional Access).

3. Configuring OAuth 2.0 / OIDC (Technical Steps)

1. Register the client app:
2. In the IdP (e.g., Google Cloud Console), register the app and get Client ID and Client Secret.
3. Set redirect URIs (e.g., https://yourapp.com/callback).
4. Implement the flow:
5. For Authorization Code Flow (recommended):
   • Redirect user to IdP’s authorization endpoint (e.g., https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=...).
   • Exchange the code for tokens at the IdP’s token endpoint.
   • Validate the ID Token (OIDC) or Access Token (OAuth).
6. Store tokens securely:
7. Use HTTP-only, Secure, SameSite cookies for web apps.
8. For mobile apps, use secure storage (e.g., Android Keystore, iOS Keychain).
9. Handle token expiration:
10. Use refresh tokens to obtain new access tokens silently.

4. Monitoring and Maintenance

• Log and audit: Monitor authentication events (e.g., failed logins, token issuance) using SIEM (e.g., Splunk, Azure Sentinel).
• Rotate secrets: Regularly rotate Client Secrets, SAML signing certificates, and encryption keys.
• Deprovision users: Use SCIM to automatically revoke access when users leave the organization.

Common Mistakes

Certification Exam Tips

CISSP

• Focus on governance: Understand federation risks (e.g., single point of failure, IdP compromise) and how to mitigate them (e.g., MFA, IdP redundancy).
• SAML vs. OAuth vs. OIDC: Know the use cases:
• SAML: Enterprise SSO (e.g., corporate apps).
• OAuth: Delegated authorization (e.g., third-party app access).
• OIDC: Authentication + OAuth (e.g., "Log in with Google").
• Token security: Memorize that JWTs are signed, not encrypted by default. Encryption requires JWE (JSON Web Encryption).

Security+

• Ports and protocols: Know that SAML uses HTTPS (443), LDAP uses 389/636, and OAuth/OIDC use HTTPS.
• Flows: Be able to identify the Authorization Code Flow as the most secure OAuth flow.
• Attacks: Understand SAML replay attacks (reusing assertions) and OAuth token theft (e.g., via XSS).

CEH

• Attack vectors: Focus on:
• SAML vulnerabilities: XML signature wrapping, misconfigured assertions.
• OAuth attacks: CSRF (via state parameter), token leakage (e.g., in logs).
• JWT attacks: Algorithm confusion (e.g., switching RS256 to HS256), none algorithm.
• Tools: Know how to use Burp Suite to intercept/modify SAML/OAuth requests.

Quick Check Questions

1. A company wants to allow employees to log into Salesforce using their corporate Azure AD accounts. Which protocol is most appropriate?

A) OAuth 2.0 B) OpenID Connect C) SAML 2.0 D) LDAP

✅ Correct Answer: C) SAML 2.0
Explanation: SAML is the standard for enterprise SSO (e.g., corporate apps like Salesforce). OAuth/OIDC are better for consumer apps, and LDAP is a directory protocol, not a federation standard.

2. During an OAuth 2.0 flow, a mobile app receives an access token. What is the primary risk if the token is stored in localStorage?

A) The token may expire too quickly.
B) The token could be stolen via a cross-site scripting (XSS) attack.
C) The token will not work with refresh tokens.
D) The token will be encrypted by default.

✅ Correct Answer: B) The token could be stolen via a cross-site scripting (XSS) attack.
Explanation: localStorage is accessible via JavaScript, making it vulnerable to XSS attacks. Tokens should be stored in HTTP-only cookies or secure mobile storage.

3. A security team is investigating a breach where attackers modified SAML assertions to impersonate users. What is the most likely cause?

A) The IdP’s signing certificate was not validated by the SP.
B) The SP used the Implicit Flow instead of Authorization Code Flow.
C) The access tokens were not encrypted.
D) The refresh tokens were stored in a database.

✅ Correct Answer: A) The IdP’s signing certificate was not validated by the SP.
Explanation: If the SP does not validate the SAML signature, attackers can tamper with assertions (e.g., change the NameID to impersonate another user).

Last-Minute Cram Sheet

1. SAML = XML-based, enterprise SSO (e.g., corporate apps). Port: 443 (HTTPS).
2. OAuth 2.0 = Delegation (authorization), not authentication. Flows: Authorization Code (most secure), Implicit (deprecated).
3. OpenID Connect (OIDC) = OAuth 2.0 + authentication. Uses JWTs (ID Tokens).
4. JWT = header.payload.signature. Not encrypted by default (use JWE for encryption).
5. IdP = Identity Provider (e.g., Azure AD, Okta). SP/RP = Service Provider/Relying Party (e.g., Salesforce).
6. SAML Assertion = Signed XML from IdP to SP. Must validate signature to prevent tampering.
7. OAuth Tokens:
8. Access Token = Short-lived (e.g., 1 hour).
9. Refresh Token = Long-lived (rotate to prevent theft).
10. PKCE (Proof Key for Code Exchange) = OAuth extension to prevent authorization code interception (used in mobile/web apps).
11. ⚠️ Common Attack: SAML Replay (reuse assertions). Mitigate with short-lived assertions and unique IDs.
12. ⚠️ Common Attack: OAuth Token Theft (e.g., via XSS). Mitigate with HTTP-only cookies and CSP headers.