SAML2 vs OpenID Connect: How Federated Authentication Works

Izahir

— 2 min read

Every time you click “Login with Microsoft or Google” you’re experiencing something called federated authentication.

It’s a form of Single Sign-On (SSO) that allows you to access multiple services without creating a new username and password for each. Instead, you sign in once with a trusted identity provider (IdP).

Example of trusted IdPs:

  • Social Providers such as Google, Apple, or Facebook
  • Corporate Providers like Microsoft, Okta, or Ping Identity
  • Government-backed Providers such as eIDAS in the EU (for cross-border authentication), DigiD in the Netherlands, or Gov.uk One Login in the UK

Behind the scenes, this trust is enabled by federation protocols such as SAML 2.0 and OpenID Connect (OIDC).

🔐 What SAML 2.0 Does

Think of SAML2 like getting a signed letter of introduction from a trusted authority for your application .

  1. You try to open an app (the Service Provider, or SP).
  2. The app says: “I don’t know you. Please get proof from your Identity Provider (IdP).”
  3. The app redirects you to the Identity Providers login page and authenticate yourself using password, fingerprint, MFA, etc.
  4. After completing these steps, the IdP writes a special XML document called a SAML Assertion.
  5. That XML assertion is digitally signed so it cannot be forged or tampered with.
  6. You’re redirected back to the app, carrying the assertion. The app verifies the signature and trusts the IdP’s word — without ever seeing your password.

🔐 What OpenID Connect Does

OpenID Connect (OIDC) works in a similar way, but instead of XML, it uses a modern JSON format that’s easier for apps and developers to handle.

When you log in with OIDC:

  1. You try to access an app (the Relying Party, or RP).
  2. The app says: “Go ask your Identity Provider (IdP) to confirm who you are.”
  3. The app redirects you to the Identity Providers login page and authenticate yourself using password, fingerprint, MFA, etc.
  4. The IdP creates a JSON Web Token (JWT), also called an ID Token.
  5. That JSON token says: “This person is Alice, she logged in at 9:05 AM, and here’s my signature to prove it’s authentic.”
  6. The app checks the signature of the JWT, trusts the IdP, and lets you in.

🆚 Why Choose One Over the Other?

To enable federated authentication, both SAML 2.0 and OIDC are established choices with broadly similar processes.

  • SAML 2.0 (2005) is mature, battle-tested, and dominant in enterprises, especially for Single Sign-On (SSO) across legacy business apps. However, the protocol itself is stable and not evolving much further.
  • OpenID Connect (2014) is still actively developed by the OpenID Foundation and has a growing ecosystem. It goes beyond federated authentication into areas like interoperability, consent management, financial-grade API security frameworks (FAPI), verifiable credentials, KYC and Identity Assurance (eKYC & IDA), and modern authorization models.

Conclusion

If an existing system already supports SAML 2.0 for SSO, it makes sense to use it. But for greenfield projects or when both protocols are viable options OpenID Connect is the better choice, thanks to its extensibility and active evolution.

Both SAML 2.0 and OIDC are secure and widely adopted, but the industry trend is clear: OIDC is the modern standard, supported by an active community and designed for a broader range of use cases.

The good news? Many organizations run both side by side today — SAML2 for legacy, OIDC for the future.

📚 Further Reading

Read more