SAML vs. OIDC: Choosing the Right Protocol

If I had to boil it down to one rule, it’s this: use SAML for browser-based enterprise sign-on, and use OIDC for new web, mobile, SPA, and API-led apps.

If you’re choosing between the two, I’d focus on four things first:

• App type: browser-only vs web, mobile, and APIs
• Setup work: manual SAML metadata vs OIDC discovery and JWKS
• Key rotation: more vendor coordination in SAML, less manual work in OIDC
• Buyer demand: many enterprise customers still ask for SAML 2.0 in security reviews and RFPs

In plain terms, both protocols let users sign in once and access more than one system. But they do it in different ways:

• SAML sends XML assertions through the browser
• OIDC uses JSON/JWT tokens and standard endpoints
• SAML is often a better match for older enterprise SaaS and B2B federation
• OIDC is often a better match for cloud apps, mobile sign-in, and service-to-service access
• In mixed estates, the answer is often both

For many UK teams, the main issue is not theory. It’s day-to-day work. SAML can mean more manual setup, more certificate tracking, and more per-customer configuration. OIDC often cuts that load with /.well-known/openid-configuration, JWKS, and PKCE.

OIDC vs. SAML: What’s the Best Choice for Identity Federation? | Beyond Talks

Quick Comparison

My short take: if your buyers are large enterprises, you may need SAML even if you’d rather build around OIDC. If you’re starting from scratch, OIDC is usually the simpler choice for most new app stacks.

The rest of the article breaks down how each one works, where each fits, and when dual support makes sense.

How SAML and OIDC work

The real difference comes down to how each protocol passes identity data and how much day-to-day work that creates for your team.

How SAML works in enterprise SSO

SAML SSO follows a fairly direct sequence. A user tries to access a service provider (SP). The SP sees that there’s no active session and sends a SAML authentication request to the identity provider (IdP), usually through a browser redirect. The IdP then authenticates the user, signs an assertion, and posts it back to the ACS endpoint. The SP validates the XML signature, checks the assertion conditions, maps the attributes to a local user, and opens a session.

To make that work, the IdP and SP have to exchange SAML metadata. These are XML documents that describe each side’s entity ID, endpoints, and X.509 certificates. On paper, that sounds neat. In practice, it often means manually importing metadata files, keeping an eye on certificate expiry dates, usually every one to three years, and lining up updates with outside partners. In B2B setups, UK organisations often end up keeping separate federation configurations for each customer’s IdP, with its own attribute mappings and NameID format settings.

Assertions are digitally signed with XML Signature and can also be encrypted with XML Encryption. That gives SAML a lot of depth, but it also adds work. Encrypted assertions are hard to inspect when something breaks. Certificate rotations need careful coordination on both sides. And XML parsing has to be done properly to avoid security issues such as signature wrapping attacks. So when teams size up SAML, the main concerns are usually metadata management, certificate rotation, and XML handling.

How OIDC works in web, mobile, and API-driven apps

OIDC aims for the same sign-in result, but it moves the exchange to tokens and standard endpoints. Instead of XML, it returns a signed ID token after an authorisation code exchange. In the authorisation code flow, the user visits a client application, which redirects them to the OpenID Provider's (OP's) authorisation endpoint and asks for scopes such as openid, profile, and email. After the user signs in, the OP redirects back with an authorisation code. The client application sends that code to the token endpoint and gets back an ID token - a signed JWT with claims about the user, including sub (a stable user identifier), email, iss (issuer), and exp (expiry). The client application validates the token and starts a session.

Where OIDC tends to be simpler to run over time is its discovery mechanism. Every OP publishes a well-known configuration document at /.well-known/openid-configuration, which lists its endpoints, supported scopes, and a JWKS URL where clients can fetch the current public keys. That changes the admin work quite a bit. Certificate rotations can happen automatically because client applications can pick up new keys without manual updates.

OIDC also fits modern app patterns well. For mobile apps and single-page applications, it supports the authorisation code flow with PKCE (Proof Key for Code Exchange), which stops authorisation code interception. For microservices and APIs, short-lived JWT access tokens can be checked locally by each service, so there’s no need to call the OP on every request. In horizontally scaled cloud-native architectures, that gives a clear edge on performance and resilience.

These mechanics set up the trade-offs in the next section.

SAML vs. OIDC: side-by-side comparison

::: @figure {SAML vs OIDC: Side-by-Side Protocol Comparison} :::

The main gap today is less about theory and more about day-to-day delivery: how much work it takes to integrate, maintain, and run each option.

What this shows, in plain terms, is simple: SAML still works well for enterprise SSO and federation, while OIDC tends to be easier to roll out in modern app stacks.

Technical and operational differences

SAML still suits established enterprise estates, especially where older SaaS platforms and federation patterns are already in place. OIDC, by contrast, removes friction for new cloud-native builds.

The smaller JWT format also helps cut parsing overhead. That starts to matter when tokens are checked on every API request across a distributed system. It’s the sort of detail teams may ignore at first, then feel later when services start talking to each other all day long.

There’s also a clear difference in onboarding. OIDC registration is often self-service and can fit neatly into a CI/CD pipeline. SAML onboarding usually pulls in identity admins, manual setup, and change windows. That slows delivery, especially when several teams need access at once.

Security and maintenance impact

SAML brings more complexity when it comes to verification and inspection. OIDC is simpler to validate, but it still depends on getting key handling and claim validation right. So it’s not “set it and forget it” - just less awkward in most modern setups.

Certificate rotation is where the operational gap becomes obvious. In a SAML setup with dozens of SaaS integrations, renewing a certificate can turn into a long chain of emails, metadata uploads, and cutover planning just to avoid login failures. Anyone who’s done this knows the pain: one missed date, one stale file, and users are locked out.

OIDC handles this more cleanly through the JWKS endpoint. The IdP publishes new keys with updated kid values, and clients fetch them on the next refresh cycle. In practice, that means less manual coordination. SAML creates more admin work; OIDC reduces it with JWKS-based key rotation.

Attribute and claim mapping is another place where the difference shows up fast. SAML attributes often rely on long, vendor-specific URN formats, which usually means per-application mapping rules in the IdP. If one attribute is set up wrongly, users may lose the right group membership or role in the target application, sometimes with no clear error at all.

OIDC claims are more consistent. Standard names like sub, email, and name are widely understood, and custom claims can be added for roles or group membership. For organisations rolling out role-based access control or just-in-time provisioning at scale, that consistency makes life easier.

Those trade-offs shape which protocol makes sense for each application.

Choosing the right protocol for your application

Pick the protocol that fits both the app surface and the identity setup around it. In plain English: look at how the app is used, then check what the customer's IdP can support.

When SAML is the better fit

Use SAML when browser-based enterprise SSO is the main need. If your application is a workforce portal or a B2B SaaS product selling into large UK enterprises, SAML is often not just nice to have - it's something buyers expect.

That shows up early in the sales process. Security questionnaires and RFPs from finance, healthcare, and central government organisations often ask for SAML 2.0 by name, which makes it the easiest route for compliance checks and vendor onboarding [5][10].

SAML also makes sense when your federation setup is already well run. If metadata exchange is in place, certificates are monitored, and audit evidence is built around SAML flows, adding OIDC can introduce change risk without giving you much in return.

When OIDC is the better fit

Use OIDC for new SaaS, mobile, SPA and API-first apps [1][5]. Most current development frameworks, cloud-native tooling, and API gateways are built around JWT tokens and OAuth 2.0 flows.

That matters once your app moves beyond a browser login page. OIDC fits neatly with Kubernetes-based microservices, serverless backends, and mobile SDKs on iOS and Android - areas where SAML's browser-only flow starts to feel like the wrong tool for the job [1][7][9].

It's also the natural choice for customer identity use cases, such as social login, self-service registration, and consumer-facing platforms. For new builds, OIDC is usually the default. SAML tends to come in when outside buyer or compliance demands push you there [6][13][14].

How protocol choice affects architecture and delivery

This choice shapes more than the sign-in flow. SAML points you towards a browser-centred setup, while OIDC pushes you towards a token-centred model [8][9][11].

For B2B SaaS products aimed at mid-to-large enterprises, the practical answer is often dual-protocol support. That means routing each customer to SAML or OIDC based on their IdP and procurement needs, often mapped by email domain or tenant identifier [2][6][4].

Why does that help? It cuts friction in the sales cycle and keeps your core application separate from customer-by-customer federation details.

If your organisation is partway through a cloud migration, a sensible path is to keep SAML for stable, browser-centred legacy apps that are being lifted and shifted, while bringing in OIDC as you containerise services, add APIs, or build mobile channels [3][12][14].

Conclusion: a practical decision framework

The choice between SAML and OIDC is an architecture decision, not just an authentication one. It should come down to the type of application you run, the IdP support your customers already have, your security and compliance needs, and the cost of running it all.

Here’s the plain-English rule of thumb: use SAML for browser-based enterprise SSO, and use OIDC for new SaaS, mobile, SPA, and API-driven services. [1][5][17][19]

In most cases, a short architecture review settles the matter. If the app is browser-only and the target IdPs are already set up for SAML, go with SAML. If the app works across multiple channels or leans on modern IdPs, OIDC is usually the better fit. Write that split down in a one-page identity standard so every team follows the same rule. The point here isn’t protocol theory. It’s stopping teams from making different federation choices for similar systems. [15][16]

Once that line is set, migration can happen in phases. If your estate is heavy on SAML, start by adding OIDC to new builds first. Then move older apps over in batches. [15][16][18] Hokstad Consulting supports hybrid identity design and migration automation.

FAQs