What’s the Difference Between SAML and OIDC?

TL;DR

Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) both let users log in using accounts from another system, like Google or your company’s identity provider. But they work differently.

SAML is older and based on XML. It’s still the dominant standard for enterprise single sign-on.
OIDC is newer, JSON-based, and designed for modern web and mobile apps. While sometimes used for enterprise single sign-on with providers like Okta, it’s most recognizable as the protocol that powers social logins (e.g., Login with Google).

Common Misconceptions

SAML and OIDC are the same thing.

SAML and OIDC are not the same thing. They solve similar problems (authenticating users without asking for a password), but they use different technologies.

SAML is its own arcane, XML-based standard
OIDC is a modern identity layer, built on top of OAuth 2.0, using JSON Web Tokens (JWTs).

OIDC is less secure than SAML.

OIDC is well-suited to modern systems. It uses modern encryption, short-lived access tokens, and lets you control exactly what data is shared. Both OIDC and SAML can be very secure—what matters most is the quality of the implementation.

SAML is fundamentally insecure. I should implement OIDC only.

SAML has its issues, don’t get me wrong. It’s very easy to implement SAML incorrectly and run into security problems. Nonetheless, SAML remains the dominant standard that nearly all enterprises use for single sign-on. It is not practical to expect all of your customers to accommodate OIDC-based single sign-on.

SAML is obsolete

SAML is older than OIDC, and it will likely go away in time, but it’s still the dominant standard. If you're selling to big companies, especially in industries like healthcare and financial services, SAML is probably a requirement. You may not like it, and it may not be glamorous, but it’s dependable; and often required for enterprise compliance.

I can implement SAML myself.

No matter your skill level, implementing SAML yourself is almost always a bad idea. SAML is really, really weird; it relies heavily on XML digital signatures, for example. Open source libraries routinely invite grievous security vulnerabilities. You really need to be careful. In most cases, it makes sense either to use a hosted provider like Auth0 or Tesseral or to use something like Keycloak or SSOReady as a SAML server.

What is SAML?

SAML stands for Security Assertion Markup Language.

Imagine you’re in line to attend an event. Instead of showing your ID at the door, the security guard at the front of the line hands you a signed permission slip that says “Yes, I vouch for this person.” That’s essentially what SAML does. It’s a way for an Identity Provider (IdP) like Okta to vouch for a user trying to access a system, like Salesforce or Workday.

For a more detailed explanation of SAML, how it works, how it fits into your product and your customer’s business, see our technical primer here.

saml-sequence-diagram

Tesseral comes with SAML SSO out of the box, meaning you don’t need to write any additional code to enable it for a given customer. Read our full SAML setup guide here.

What is OIDC?

OIDC stands for OpenID Connect and it’s built on top of OAuth 2.0.

Think of OIDC like a digital keycard you scan to get into a building. OAuth 2.0 is all about access: getting permission to do something, like access your calendar. OIDC adds identity, meaning it confirms who you are. It’s like printing your name on your keycard. When you click “Login with Google,” for example, for a given app, the app will redirect you to Google, you’ll log in there, and it will then send back a JWT (ID token) that confirms you are … well … you. Once the app verifies that token, it will start a session and log you in.

oidc-diagram

Tesseral supports OIDC with built-in flows and SDKs that enable you to let users login via Google, GitHub, and Microsoft, add your customers’ IdPs dynamically (either self-serve or via API), handle token exchange, refresh, and validation, and more.

When should I use SAML vs. OIDC?

Use SAML when:

You’re working with enterprises that already use IdPs like Okta or ADFS
Your customers want centralized access control for internal apps
You’re integrating with legacy systems, like HR platforms, finance, or compliance tooling
You’re okay doing some manual configuration

Use OIDC when:

You’re building less enterprise-y applications
You want social login options (Google, GitHub, etc.)
You’re offering a self-serve product or developer onboarding
You can’t do manual set-up for each customer

saml-oidc-table