SAML vs. OIDC: the protocol question behind every SSO project, explained

The question rarely comes from developers: it sits in procurement's security questionnaire, somewhere between the ISO certificate and the data processing agreement. As soon as your software or portal goes to enterprise customers, their IT demands single sign-on via the company's own identity provider (IdP), the organization's central login service. And in many corporations, that service speaks a protocol called SAML.

Behind it lies the protocol question of every SSO project: SAML or OIDC? Both standards solve the same problem — an application delegates login to a trusted identity service instead of managing passwords itself. They merely come from different eras of web history, and precisely this age gap produces most of the misunderstandings.

Why this matters to you as a decision-maker: in a vendor review, a single unanswered "Do you support SAML?" can stall a five-figure annual contract for weeks. This article explains both protocols without a single line of code: what they are, how they differ, and how you decide without putting a deal at risk.

First, the definition: SAML stands for Security Assertion Markup Language and is an XML-based standard an identity provider uses to confirm to an application who has just signed in. The version in use today, 2.0, is an OASIS standard dated March 15, 2005 — and it has been in service essentially unchanged ever since.

The everyday picture: a SAML assertion is a certified deed. Your application sends the user to the "registry office", the identity service of their employer. There they prove who they are, and back comes a digitally signed document: this person is Ms. Meier from procurement, verified and sealed. Formal and wordy — but recognized throughout corporate business.

The format fits the era: in the early 2000s, XML was the lingua franca of corporate IT, and SAML messages are correspondingly verbose. For humans they are tedious to read; for the systems of that time they were ideal. The bulkiness is not a flaw, it is a timestamp.

The origin explains the character: SAML was built for federation, the trust relationship between organizations. The classic case: employees of a corporation sign in to a service provider's software with their company account, without ever holding a password there. Departing employees automatically lose every access — for corporate IT, that is the real value.

Two roles are worth knowing, because they come up in every integration call: the identity provider (IdP) confirms identities, and the service provider (SP) is the application that trusts this confirmation — in an enterprise deal, you are the service provider. The trust between the two is set up once, by exchanging metadata and certificates.

The rule of thumb: SAML was built for browsers and the office world — web applications in a corporate environment, not apps on a smartphone.

Again, the definition first: OIDC stands for OpenID Connect and is an identity layer on top of OAuth 2.0, a framework for delegated access. The OpenID Foundation finalized the standard on February 25, 2014. Instead of XML documents, OIDC uses compact JSON payloads; the centerpiece is the ID token in JWT format (JSON Web Token).

The everyday picture here: an ID token is a digital boarding pass. Small, machine-readable, cryptographically protected against forgery — and it works everywhere: in the browser, in a native app, at the API. Your application reads the pass and knows within milliseconds who is standing in front of it and how long the login is valid.

Its origin is the counter-world to SAML: OIDC was designed by Google, Microsoft, and other web companies for the time after the smartphone breakthrough. Single-page applications, native apps, APIs, microservices: everywhere there, OIDC is the standard route today. Every "Sign in with Google" on a website is technically OIDC.

Add the ecosystem: modern methods such as passkeys and multi-factor authentication dock onto OIDC infrastructure first, and practically every current library ships with support built in. For you, that means shorter project timelines and less specialist knowledge in the team when OIDC is the route.

The core in one sentence: OIDC delivers the same certified confirmation as SAML — just in the format of modern web and app development.

For orientation, the most important differences side by side. The table does not replace an architecture decision, but it shows the pattern behind all the details: SAML is the established standard of corporate IT, OIDC the standard for everything new.

A reading note on the last row: "higher" does not mean unmanageable. SAML integrations are routine when the tooling is right — with a well-practiced setup, we budget one to three days of effort per enterprise IdP. It does mean: more configuration details, more coordination with the other side, more patience when debugging.

The good news first: you have to choose less often than the headline suggests. The real question is not "which protocol is better" but "who dictates the protocol". Three constellations cover almost all projects.

Your customer brings an enterprise IdP: then their system sets the pace. ADFS, older Entra ID configurations, and many SAP and HR landscapes speak SAML — and no corporate IT changes its identity infrastructure for a single vendor. If you only offer OIDC here, you lose the deal or spend weeks negotiating workarounds.

You are building new applications: then OIDC is the given. Every current web and app technology ships with support, the tokens fit APIs and microservices, passkeys and MFA slot right in. Building a new system exclusively on SAML would be a decision against the current in 2026.

You need both: the normal case in B2B. Your applications speak OIDC internally, your enterprise customers deliver identities via SAML. That is exactly what identity brokers are for: Keycloak speaks both protocols at the same time and translates between them — your application never notices. You connect new customer IdPs through configuration, not through code.

For planning, this means: protocol capability belongs in the architecture before the first enterprise customer demands it. The broker costs a few project days at the start; retrofitting it under a running system costs a multiple — including the migration of all existing accounts.

In practice, this bridge is standard fare in customer portal projects: SSO toward the customer's IdP on one side, your application's own login on the other. And if Keycloak is not a given for you: most Keycloak alternatives handle both protocols as well. Answer the protocol question separately from the product question — first the need, then the tool.

Condensed into two sentences: you speak SAML because your customers speak it. You speak OIDC because your applications speak it — and a broker makes sure both hold true at the same time.

To close, the four sentences that cause the most confusion in protocol discussions — and what is true instead.

"SAML is outdated": half right, entirely misleading. The standard dates from 2005 and is no longer being developed — but that does not make it useless, it makes it finished. Millions of corporate logins run through it every day, and no corporation replaces its federation on short notice. The only outdated move would be building a new system exclusively on SAML.

"OAuth2 is a login protocol": no. OAuth 2.0 (RFC 6749, IETF, October 2012) governs authorization, meaning delegated access to resources. Who the user is, the specification does not settle — it explicitly declares authentication out of scope. The everyday picture: OAuth2 is the hotel key card. It opens doors, but it is not an ID. Only OIDC adds the ID.

"OIDC is less secure because it is simpler": the opposite is closer to the truth. Simpler standards get implemented correctly more often, and the failure classes of XML signatures (signature wrapping, for one) accompanied SAML implementations for years. In both worlds, security comes from clean implementation and maintained libraries, not from the protocol label.

"We have to commit to one": you do not. The protocol question is decided per integration, not per company. One central identity service serves the enterprise customer's SAML requirement and your own app's OIDC login from the same user directory — no duplicate accounts, no duplicate upkeep.

Is a security questionnaire with the SAML question sitting on your desk right now? Then the answer is rarely a rebuild and usually a manageable architecture decision. We build customer portals with exactly this bridge architecture: OIDC for the application, SAML for the enterprise connection — matched to the identity providers your customers actually bring.

In a free initial consultation, we clarify your specific case in 30 minutes: which identity providers your customers use, whether you need a broker, and what the integration will cost. You get an honest assessment — even when the answer is: you do not need us for this.