SSO vs OIDC vs SAML

Published 18 October 2026

You open Gmail in the morning and sign in. Then you open YouTube, Google Drive and Google Calendar, and none of them asks you anything. At work, you sign in to Okta once and then Slack, Jira, Workday and AWS all open straight away. That experience has a name: single sign on, or SSO.

SSO is not a protocol. It is the result. OIDC and SAML are two different protocols that produce that result. Asking "SSO or OIDC?" is like asking "travel or train?". You travel by train. You get SSO by OIDC, or by SAML.

Three parties, every time#

Every SSO setup has the same three roles. The names change between the two protocols, which is half of why people find this confusing.

• You, in a browser.
• The app you want to use. SAML calls it the service provider (SP). OIDC calls it the relying party (RP), because it relies on someone else to say who you are.
• The identity provider (IdP), the one place that actually checks your password and your second factor. Okta, Microsoft Entra ID, Google, Keycloak.

The app never sees your password. It sends you to the identity provider, the identity provider checks you, and sends you back with a signed note that says "this is Asha, I checked". In SAML that note is called an assertion and it is XML. In OIDC it is called an ID token and it is a JWT. That is most of the difference.

Why the second app needs no password#

This is the part to understand properly, because it answers the question at the top. When you sign in at the identity provider, it sets its own session cookie on its own domain, say acme.okta.com. Every app is still a stranger. But the next time any app sends you to acme.okta.com, your browser brings that cookie along, the identity provider recognises you, and sends you straight back with a fresh assertion. The redirect takes a few hundred milliseconds and you never see a login page.

So SSO is really two sessions layered on each other: one long session at the identity provider, and one per app. That also explains why single log out is famously unreliable. Signing out of Slack ends Slack's session, but Okta's session and Jira's session are still alive. Ending all of them means the identity provider has to notify every app, and SAML's and OIDC's logout specs for that are both patchily implemented.

SAML: the enterprise veteran#

SAML 2.0 was published by OASIS in 2005, before smartphones and before JSON was everywhere. The assertion is an XML document, signed with XML Signature, carried by the browser in a hidden form POST. It is verbose and the XML signature rules are subtle, which has produced a long line of "signature wrapping" bugs where an attacker moves the signed part and slips in an unsigned one. Use a well tested library. Never parse it yourself.

What SAML has is twenty years of enterprise adoption. Every corporate identity provider speaks it, and so does almost every B2B SaaS product. If a bank's IT team asks your startup "do you support SSO?", they usually mean "can we connect our SAML IdP to your app?".

OIDC: OAuth plus an ID token#

OpenID Connect (2014) is a thin identity layer on top of OAuth 2.0. OAuth on its own is about authorization: it gives an app an access token to call an API, and says nothing reliable about who the user is (see authentication vs authorization). OIDC adds the ID token, a signed JWT meant for the app itself:

{
  "iss": "https://accounts.google.com",
  "sub": "110248495921238986420",
  "aud": "your-client-id.apps.googleusercontent.com",
  "email": "asha@gmail.com",
  "iat": 1760774400,
  "exp": 1760778000,
  "nonce": "n-0S6_WzA2Mj"
}

The app must check that the signature is valid, iss is the identity provider it expects, aud is its own client id, exp is in the future and nonce matches the one it sent. Use sub, not email, as the user's key: emails get changed and reused, sub never does.

OIDC uses the OAuth authorization code flow with PKCE (covered in OAuth 2.0 flows), JSON instead of XML, and a discovery document at /.well-known/openid-configuration that lists every endpoint and signing key, so setup is often a single URL. It works the same in a browser, a mobile app or a CLI. "Sign in with Google" and "Sign in with Apple" are OIDC.

In the interview#

The common prompt is not "explain SAML". It is a design question with SSO inside it.

Checkpoint#