The SSO Crossroads: Navigating SAML and OIDC
Every team building B2B software eventually hits the same wall: a serious client demands Single Sign-On (SSO). The internet offers two acronyms, OIDC and SAML, each claiming to be the definitive answer. Charts abound, labeling SAML as 'enterprise' and OIDC as 'modern,' leaving developers just as bewildered as before. This guide cuts through the noise to help you deliver what your clients truly need.
What Are SAML and OIDC?
SAML, born in 2005, is fundamentally XML-based. An Identity Provider (IdP) signs an assertion—essentially, a statement like 'this is alice@bigco.com, and here are her groups'—and sends it to your application. Your app then verifies the signature and logs Alice in. SAML was designed for browser-based workflows and employee identity within traditional corporate networks, which at the time meant on-premises Active Directory and SOAP stacks. It's verbose, it's old, and it's deeply entrenched in large organizations. That's the only fact you need to remember about SAML's prevalence.
OIDC (OpenID Connect), emerging in 2014, leverages JSON and JWT (JSON Web Tokens) on top of the OAuth 2.0 framework. The IdP issues an ID Token, which your application validates. OIDC is built for the modern web: Single Page Applications (SPAs), mobile apps, APIs, and social logins. It's more concise, offers a more complete specification for the systems you're likely building today, and is the protocol of choice for most new identity solutions.
When Does Each Protocol Shine?
The honest answer to 'which one should I build?' is usually: you don't get to choose. You build what your client's IT department has already selected, often long before they ever heard of your product.
Here's a breakdown of common scenarios:
- Clients using Okta, Entra ID (formerly Azure AD), or Google Workspace often support both SAML and OIDC. However, OIDC is generally the smoother, more modern path for these IdPs.
- Clients with legacy on-premises IdPs, such as older versions of Active Directory Federation Services (ADFS) or systems specified in procurement lists from years ago, will likely hand you SAML metadata and expect that to be the end of the discussion.
- Your own first-party applications—your customer dashboards, internal tools, and mobile clients—require OIDC. There's virtually no reason to implement SAML for users logging into your own React or Vue.js application.
This effectively divides the landscape. If your client is a large, established enterprise with a mature IT department, expect SAML. If your client is a growing tech company, a startup, or uses modern cloud-based identity providers, OIDC is far more likely. Sometimes, you'll need to support both.
Technical Considerations and Implementation
Implementing SAML involves parsing XML, managing certificates for signing and encryption, and handling complex redirects. The SAML assertion itself can be quite large, containing user attributes and group memberships. While robust and secure, its verbosity and reliance on XML can make debugging and integration challenging, especially for developers accustomed to JSON-based APIs.
OIDC, by contrast, is significantly simpler. It uses JSON Web Tokens (JWTs) for identity information, which are compact and easy to parse. The flow is typically more straightforward, involving an authorization code exchange that results in an ID Token and potentially an Access Token. This makes OIDC a much better fit for APIs, mobile applications, and modern web architectures where performance and ease of integration are paramount.
The underlying OAuth 2.0 framework that OIDC builds upon is an authorization framework, not an authentication protocol. OIDC adds the identity layer on top, specifying how to obtain identity information about the end-user. This distinction is crucial: OAuth 2.0 is about granting access to resources, while OIDC is about verifying who the user is.
The Future is OIDC
While SAML will remain relevant for years due to its deep integration in enterprise environments, OIDC is the protocol of the future. New identity solutions, cloud-native applications, and the proliferation of APIs all point towards OIDC as the standard. For new B2B integrations, particularly those involving mobile or API access, OIDC should be your default choice unless a client explicitly requires SAML.
If you're developing a new product or integrating with a new customer, understand their existing identity infrastructure. Forcing a SAML integration into a modern SPA is like trying to fit a square peg into a round hole. Conversely, if a large enterprise client mandates SAML, trying to push OIDC might lead to significant friction and delays. The key is to be prepared for both, but to advocate for OIDC when building your own platform services.