SAML vs OIDC

At a glance

The technical comparison is short, because the protocols overlap almost entirely in what they achieve. Where they differ is in shape and era.

Which one you will be asked for

You rarely get to choose. The customer's IT team has a platform, that platform has a preferred integration path, and your job is to accept whichever one they hand you.

In practice: large, established organisations with an on-premise heritage lean SAML, often because their existing catalogue of integrations is SAML and consistency is worth more to them than modernity. Companies built in the last decade, and anything driven by a developer team rather than an IT department, lean OIDC.

Both will appear in your customer list within the first year of selling to enterprises. Supporting only one is a deal you will lose without hearing why.

What each costs you if you build it yourself

The gap between the two is widest not in the happy path but in everything around it.

• SAML: XML canonicalisation and signature verification, which is subtle enough that several well-known libraries have shipped signature-wrapping vulnerabilities. Certificate lifecycles measured in years, so rotations surprise you. Metadata files exchanged by email.
• OIDC: JWT verification with correct issuer, audience and nonce checks. Key rotation handled through a cached JWKS. Far less code, but the checks that are easy to omit are the ones that matter.
• Both: per-customer configuration storage, a routing rule from email domain to connection, an admin surface for setup, and a support path for when a provider changes something without telling anyone.

What does not differ

Some things are the same whichever protocol you accept, and they are the parts most likely to bite you.

• You still need a stable identifier that is not email. Both protocols offer one; both make it easy to use the wrong field.
• You still need to decide what happens when an authenticated person has no account in your product yet. Auto-provision, refuse, or hold for approval — each is defensible, and silence is not.
• Neither protocol deprovisions anybody. When someone leaves, SSO stops them signing in; their account and its data remain until something else removes them.
• Neither carries authorisation. Groups may arrive as claims, but what they mean in your product is your model's decision.

The same profile either way

This is the profile your callback receives from a Paycux connection. The connectionType field is the only place the protocol is visible; nothing else in your code needs to know.

1const { profile } = await paycux.sso.getProfileAndToken({
2  clientId: process.env.PAYCUX_CLIENT_ID,
3  code,
4});
5 
6// SAML ya da OIDC — govde ayni
7await upsertUser({
8  externalId: profile.idpId,
9  email: profile.email,
10  firstName: profile.firstName,
11  lastName: profile.lastName,
12  organizationId: profile.organizationId,
13});

A short recommendation

If you are choosing for a greenfield integration where the other side is flexible, take OIDC: less code, better fit for mobile and single-page clients, and key rotation that does not require a human.

If you are selling into enterprises, plan for both from the start — not by writing both, but by making the protocol a property of a connection rather than an assumption baked through your sign-in path. That single decision is what keeps the second protocol from being a rewrite.

Related