Differentiating Federated Identities: OpenID Connect, SAML v2.0, and OAuth 2.0

The gradual integration of external applications and services beyond an organization’s internal domain motivated the creation and continued evolution of federated identity systems.
Single Sign-On (SSO), an early form of centralized authentication, allowed users to access multiple internal resources using a single credential. However, as organizations began adopting high-quality third-party SaaS tools, identity management had to extend across trust boundaries. Federated identity enables that expansion — maintaining SSO’s convenience while extending trust securely to external systems.

This article examines three protocols that form the backbone of modern identity federation: OpenID Connect (OIDC), SAML v2.0, and OAuth 2.0.

Federated identities shouldn't be mixed up with Single Sign On, here is a video that explains the difference

‍OpenID Connect

Origin & Evolution:‍

OpenID Connect (OIDC) was released in February 2014 by the OpenID Foundation, backed by Google, Microsoft, PayPal, and others. It extends OAuth 2.0 (RFC 6749, 2012) with an identity layer that verifies who a user is — not just whether they’re authorized.

Who Uses It:

‍OIDC powers nearly all modern web and mobile login systems. If you’ve ever clicked “Sign in with Google,” “Sign in with Microsoft,” “Sign in with Apple,” or authenticated to AWS, Okta, Auth0, or Ping Identity, you’ve used OIDC. It’s the de facto standard for consumer identity and modern SaaS platforms because it’s developer-friendly, JSON-based, and mobile-ready.

How It Works:
OIDC defines three entities:

• End User – the individual being authenticated.
• Relying Party (Client) – the app seeking to verify identity.
• OpenID Provider (OP) – the trusted IdP (e.g., Google, Okta) that authenticates the user and issues a signed ID Token (JWT).

OIDC uses RESTful APIs, HTTPS, and JWT/JWS/JWE for compact, verifiable identity assertions.

‍

The following diagram illustrates an OpenID Connect use case: 

Security Considerations

1. Mix-Up Attacks (2016)
   Attackers can confuse a Relying Party about which provider issued an authorization code, leading to token theft.
   ✅ Modern mitigation: Bind authorization responses to the expected issuer (iss parameter) and use the OAuth 2.0 Security Best Current Practice recommendations.
2. Covert Redirect (2014)
   An open-redirect bug at the Relying Party can allow attackers to hijack redirect URIs for phishing.
   ✅ Clarification: This is not a flaw in OIDC itself; enforce strict redirect-URI validation and eliminate open redirects.
3. Recent OIDC incidents (2020–2025)
   • Sign in with Apple (2020): Logic flaw allowed account takeover under certain token conditions.
   • CAS OIDC plugin (2024): Incorrect client-ID validation enabled impersonation.
   • IBM Verify and Apache APISIX OIDC (2024–2025): Issuer-mismatch vulnerabilities in multi-tenant deployments.
     ✅ Lesson: Always validate issuer, audience, and nonce claims and keep libraries updated.

Security Notes:

• Mix-Up Attacks (2016) – mitigated by binding authorization responses to the expected issuer and using PKCE.
• Covert Redirect (2014) – not a protocol flaw; fixed with strict redirect URI validation.
• Recent Issues (2020–2025) – authentication logic bypasses in Sign in with Apple, CAS OIDC plugin, IBM Verify, and Apache APISIX highlight the need for ongoing validation of iss, aud, and nonce claims.

✅ Why It’s Dominant: Supported by every major identity provider (Google, Microsoft Entra ID, AWS Cognito, Okta, Ping, Auth0), and standardized extensions like OIDC Federation 1.0 and OpenID for Verifiable Credentials ensure it remains the most future-proof identity protocol.

‍

SAML v2.0

Origin & Evolution:
Security Assertion Markup Language (SAML) emerged in the early 2000s, driven by enterprise identity vendors like IBM, Oracle, and Sun Microsystems, and formalized by OASIS in March 2005. It’s XML-based and designed primarily for enterprise Single Sign-On (SSO) between a company’s internal IdP and multiple external Service Providers (SPs).

Who Uses It:
SAML remains the workhorse of enterprise SSO. It underpins authentication for Microsoft Entra ID (formerly Azure AD), AWS, Salesforce, Workday, and Atlassian. While newer systems prefer OIDC for simplicity, most Fortune 500 enterprises and government agencies still rely heavily on SAML 2.0 for workforce identity federation.

How It Works:
SAML defines three core entities:

• Principal – the user.
• Identity Provider (IdP) – authenticates the user and issues SAML assertions.
• Service Provider (SP) – consumes assertions to grant access.

Assertions are XML documents signed with digital signatures and exchanged via HTTP Redirect, POST, or SOAP bindings.

The following diagram explains a use case for a SAML scenario:

Security Notes:

• XML Signature Wrapping (XSW, 2011) – mitigated by strict schema validation and signature coverage.
• HTTP Referrer Leakage (2012) – mitigated with TLS enforcement and header sanitization.
• Parser Differential Vulnerabilities (2025) – GitHub Security Lab found a “sign in as anyone” issue in ruby-saml; patching and canonicalization checks are essential.

✅ Why It’s Still Relevant: SAML’s maturity, compliance track record, and strong library ecosystem make it the preferred protocol for regulated industries (finance, healthcare, government), even as many providers migrate toward OIDC for modern apps.

‍

OAuth 2.0

Origin & Evolution:

OAuth 2.0 began in 2007 and was standardized by the IETF in 2012 (RFC 6749). It was never meant to authenticate users — only to authorize applications to access user data on their behalf. That’s why OIDC was later layered on top to add authentication.

Who Uses It:‍

OAuth 2.0 powers nearly every API access token you encounter — from Google Workspace, Facebook Graph API, and GitHub Apps to Stripe, Slack, and Zoom integrations. Any time an app asks for permission to “access your data,” it’s using OAuth under the hood.

‍

How It Works:‍

Key participants:

• Resource Owner – user who owns the data.
• Client – application requesting access.
• Authorization Server – grants access tokens.
• Resource Server – hosts the data/API.

OAuth grants access through flows like Authorization Code + PKCE, which prevent token leakage and spoofing.

The following diagram explains a user case for an OAuth scenario:

Security Considerations

Security Notes:

• Black Hat Europe 2016 Mobile SSO ATOs – rooted in apps trusting unverified client-side tokens.
• Replay and Code-Leak Attacks – mitigated via single-use codes, exact redirect URIs, and TLS.
• Modern Defenses (2020–2025) –
  • PKCE mandatory (RFC 7636)
  • OAuth 2.1 (draft) removes Implicit and Password grants
  • Mutual-TLS (RFC 8705), DPoP (RFC 9449), and JWT Access Tokens (RFC 9068) provide sender-constrained tokens

✅ Why It Matters: OAuth remains the backbone of delegated API authorization across the web. Every major cloud and SaaS provider — Google, Microsoft, GitHub, Zoom, Slack, Stripe, and AWS — depends on it for access control.

Trends:

• OIDC is winning the cloud-native world (Google Workspace, Azure AD B2C, Okta).
• SAML remains entrenched in large enterprise and compliance-heavy sectors.
• OAuth underpins both, providing secure token-based authorization for modern apps.

Emerging Alternatives

• FIDO2 / WebAuthn – passwordless authentication using biometrics and hardware keys.
• OIDC Federation 1.0 – automates trust configuration between IdPs and RPs.
• Decentralized Identifiers (DID) – blockchain-based identity ownership models gaining W3C traction.

Conclusion

Federated identity has evolved from an enterprise convenience into a global security foundation.
Each protocol — SAML, OAuth, and OpenID Connect — represents a different era of identity management:

• SAML: Enterprise-grade XML workhorse built for corporate SSO.
• OAuth 2.0: API authorization engine powering the modern internet.
• OpenID Connect: The unified authentication layer connecting everything from SaaS platforms to mobile apps.

Modern identity stacks often combine all three — SAML for workforce, OIDC for customer apps, and OAuth for API integrations — depending on legacy systems and compliance requirements.

The challenge now isn’t choosing one over the other, but integrating them securely, continuously validating configurations, and adopting the newest best practices from OAuth 2.1 and OIDC Federation to future-proof your identity ecosystem.

‍

References

• https://www.owasp.org/images/9/99/Helsinki_meeting_30_-_Threats_and_Vulnerabilities_in_Federation_Protocols_and_Products.pdf
• http://www.authenticationworld.com/Authentication-Federation/
• http://saml.xml.org/saml-specifications
• http://en.wikipedia.org/wiki/Federated_identity
• http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
• http://cve.mitre.org/cve/
• https://www.usenix.org/conference/usenixsecurity12/breaking-saml-be-whoever-you-want-be
• Somorovsky, Juraj, Andreas Mayer, Jorg Schwenk, Marco Kampmann, and Meiko Jensen. On Breaking SAML: Be Whoever You Want to Be.

‍