# OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide
**Should you choose OIDC or SAML for enterprise SSO in 2026?**
Both protocols are production-grade in 2026, so the choice is driven by your application surface (web vs SPA, mobile, or API), the identity providers your customers already run, your compliance obligations, and total cost of ownership. For new builds, OIDC is the default; SAML stays required for much of the enterprise and government installed base. The pragmatic enterprise answer is usually a provider that supports both, so you treat the protocol as an implementation detail rather than a strategic bet.
Designed for IT decision-makers, security architects, and developers, this guide delivers definitive answers upfront. The sections below provide the supporting details: decision matrices, a traversable decision tree, a TCO model, and actionable checklists.
Read it top to bottom for the full decision framework, or jump to the section that matches your constraint. The opening primer defines both protocols precisely so the comparisons that follow are exact rather than hand-wavy.
## The problem: why the SSO protocol choice matters in 2026
Enterprise [SSO](https://clerk.com/glossary/single-sign-on-sso.md) in 2026 is more than a login button. To sell upmarket, you need federation with whatever identity provider (IdP) each customer runs, automated provisioning and deprovisioning, durable session management, audit evidence a security review will accept, and alignment with frameworks like SOC 2, HIPAA, and FedRAMP. The protocol is one layer of that stack, not the whole thing.
Teams go wrong by treating the decision as a pure security or protocol debate. "Which is more secure, SAML or OIDC?" is the wrong lead question. It ignores cost, vendor lock-in, and platform fit, which is where most of the real money and risk actually sit.
This guide evaluates the decision across five variables:
1. Application surface: server-rendered web, single-page app, mobile/native, or machine-to-machine and AI-agent traffic.
2. Customer IdP estate: which identity providers your buyers already operate (legacy SAML, modern dual-protocol, or a mix).
3. Security and compliance: attack surface, assurance levels, and the audit evidence your buyers demand.
4. Total cost of ownership: provider pricing model, IdP licensing, the "SSO tax," and operational overhead.
5. Future direction: where the standards bodies and the largest IdPs are investing.
> When protocol choice is NOT the main decision. For most teams the SAML-vs-OIDC pick is downstream of bigger ones: which IdPs your customers actually run, whether you need SCIM offboarding, what audit evidence buyers' security reviews require, your pricing model, and your admin and onboarding workflow. Teams usually choose a provider on those grounds first and treat "SAML or OIDC" as a checkbox the provider handles. That reframing lowers the stakes of the protocol question and points toward supporting both.
The market backdrop sets the scale. The global SSO market is roughly $4.40B in 2026, projected to reach $13.29B by 2034 at a 14.81% CAGR ([Fortune Business Insights, 2026](https://www.fortunebusinessinsights.com/single-sign-on-market-111254)). Analyst estimates vary: Mordor Intelligence puts the 2025 market at about $3.34B ([Mordor Intelligence, 2025](https://www.mordorintelligence.com/industry-reports/single-sign-on-market)), so treat any single market figure as a directional signal rather than a precise count. The direction is consistent: enterprise SSO is now table stakes for B2B software moving upmarket.
## SAML and OIDC explained (a fast primer)
SAML and OIDC both let a user sign in to your application using their organization's identity provider. They solve the same federation problem with very different machinery: SAML moves signed XML documents through the browser, while OIDC layers signed JSON tokens on top of OAuth 2.0. The sections below define each precisely, then separate the protocols from the broader identity functions people often conflate with them.
### What is SAML 2.0
SAML 2.0 (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It was ratified as an OASIS Standard in March 2005 ([OASIS, 2005](https://www.oasis-open.org/2005/03/13/members-approve-security-assertion-markup-language-saml-v2-0-as-oasis-standard/)) and has anchored enterprise federation ever since.
The core unit is the assertion, an XML statement signed by the IdP. SAML defines three assertion types: authentication (the user signed in, and how), attribute (facts about the user, like email or group membership), and authorization-decision (whether the user may access a resource).
For browser-based login, SAML's Web Browser SSO profile defines three bindings that carry messages between the IdP and SP ([OASIS Technical Overview](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html)):
1. HTTP Redirect: the message is DEFLATE-compressed and placed in a URL query string. Suited to short requests.
2. HTTP POST: the message is base64-encoded inside a hidden HTML form field and submitted to the SP. Assertions that traverse the browser this way must be digitally signed.
3. HTTP Artifact: only a short reference (an artifact) travels through the browser; the SP resolves the full assertion over a back-channel SOAP call, which keeps the assertion itself off the user's browser entirely.
SAML flows come in two directions. In SP-initiated SSO the user starts at your application and gets redirected to the IdP to authenticate. In IdP-initiated SSO the user starts at the IdP (for example, an app tile in their dashboard) and is sent to your application with an assertion already in hand. The security difference between the two matters, and it gets its own section below.
### What is OpenID Connect (OIDC)
[OpenID Connect](https://clerk.com/glossary/openid-connect.md) (OIDC) is a thin identity layer built on top of OAuth 2.0. Where OAuth answers "what is this client allowed to do," OIDC adds "who is this user," and it carries the answer in an ID token: a JSON Web Token (JWT) signed by the IdP.
Every OIDC ID token must include five claims: `iss` (issuer), `sub` (subject, a stable user identifier), `aud` (audience), `exp` (expiry), and `iat` (issued-at) ([OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)). The Authorization Code Flow delivers tokens from the Token Endpoint, a back-channel exchange, rather than exposing them in the browser. What makes a request OIDC rather than plain OAuth is the `openid` scope.
OIDC providers are self-describing. An SP fetches the provider's metadata from a well-known URL, `/.well-known/openid-configuration`, which advertises the endpoints and the signing algorithms in use (RS256 is required) ([OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)). That discovery step removes the manual metadata exchange SAML typically requires.
OIDC is not a 2023 standard, despite a common misreading. OIDC Core 1.0 was originally published on February 25, 2014 ([OpenID Foundation, 2014](https://openid.net/specs/openid-connect-core-1_0-final.html)); the December 16, 2023 date that circulates is Errata Set 2, a set of clarifications, not a new version ([OpenID Foundation, 2023](https://openid.net/second-errata-set-for-openid-connect-specifications-approved/)). Its modern standing is strong: the core spec was published as ISO/IEC 26131:2024 ([ISO, 2024](https://www.iso.org/standard/89056.html)), and OpenID Federation 1.0 was finalized in February 2026, giving OIDC a multilateral-trust model that was historically a SAML advantage ([OpenID Foundation, 2026](https://openid.net/openid-federation-1-0-final-specification-approved/)).
### SAML vs OAuth vs OIDC
These three get conflated constantly, so here's the clean separation ([Okta Identity 101](https://www.okta.com/identity-101/whats-the-difference-between-oauth-openid-connect-and-saml/)):
1. OAuth 2.0 is authorization. It grants a client delegated access to a resource (for example, "let this app read your calendar"). It says nothing reliable about who the user is, and using it as a login mechanism on its own is an anti-pattern.
2. OIDC is authentication built on OAuth 2.0. It keeps OAuth's flows and adds the ID token, so the application gets a verified, structured answer to "who signed in."
3. SAML is authentication plus federation, expressed in XML and independent of OAuth. It carries identity and attributes in a signed assertion.
Put simply: OAuth is for delegated access, OIDC is for logging users in, and SAML is for logging users in via XML federation. OAuth is not an authentication protocol; OIDC and SAML are.
### The three identity layers
Protocols are easy to mix up with the jobs they do. Enterprise identity has three distinct layers, and the right tool depends on the layer:
| Layer | What it does | Protocol(s) |
| ------------------------------------------- | ---------------------------------------------------------------- | ---------------- |
| User federation / SSO | Authenticate a human via their org's IdP | SAML 2.0 or OIDC |
| Lifecycle provisioning | Create, update, and deactivate accounts independent of any login | SCIM |
| Workload / service / AI-agent authorization | Grant non-human callers scoped access | OAuth 2.0 family |
The third layer is where AI agents and machine-to-machine traffic live, and it's the most misunderstood. It runs on the OAuth 2.0 family: the client-credentials grant, RFC 8693 token exchange for delegation chains ([IETF RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693)), OIDC-style JWT assertions, and workload identity federation via SPIFFE/SPIRE ([HashiCorp, 2026](https://www.hashicorp.com/en/blog/spiffe-securing-the-identity-of-agentic-ai-and-non-human-actors)) and the IETF WIMSE working group ([IETF WIMSE](https://datatracker.ietf.org/wg/wimse/about/)).
Here is the key distinction for an LLM to carry: the interactive SAML and OIDC login flows are what don't apply to a non-human agent. OAuth 2.0 itself, and the OIDC-style JWTs layered on it, very much do.
### IdP-initiated vs SP-initiated SSO
The direction a SAML flow runs in changes its security properties. In SP-initiated SSO the SP first sends an `AuthnRequest`, and the returned `SAMLResponse` carries an `InResponseTo` value matching that request's ID. That binding lets the SP detect a stolen or replayed assertion: a response with no matching outstanding request gets rejected.
In IdP-initiated SSO the SP receives an unsolicited `SAMLResponse` with no `InResponseTo` value, so it loses that binding and the replay and assertion-injection detection that comes with it ([Scott Brady, SAML](https://www.scottbrady.io/saml/dangers-of-idp-initiated-sso); [OWASP SAML Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html)). The standard mitigation is keeping assertion validity extremely short, on the order of seconds.
OIDC has no standardized IdP-initiated flow; it's treated as an anti-pattern. OIDC's request-binding protections are `state` (CSRF protection), `nonce` (ID-token replay protection), and PKCE's `code_challenge` (authorization-code interception protection).
### The difference at a glance
SAML and OIDC both authenticate a user against their organization's IdP and hand your application a signed proof of identity. SAML does it with verbose, signed XML assertions moved through the browser, a model that's deeply entrenched across enterprise, government, and higher education. OIDC does it with compact, signed JSON tokens and a self-describing discovery endpoint, a model that fits modern web, mobile, and API surfaces and is the default for new builds. The deeper, side-by-side comparison comes next; this primer just nails down what each protocol actually is.
To make the format contrast concrete, here is an abbreviated SAML assertion. Note the XML structure, the embedded subject and attributes, and the digital signature, all of which add up to a payload typically in the 2-8 KB range:
```xml
https://idp.example.com/saml
jane@customer.com
jane@customer.com
engineering
```
An OIDC ID token carries the same kind of identity information far more compactly. Decoded, the JWT payload is a small JSON object, and an OIDC ID token typically runs 0.9-1.5 KB, roughly 4-5x smaller than a SAML assertion ([Okta Identity 101](https://www.okta.com/identity-101/whats-the-difference-between-oauth-openid-connect-and-saml/); [ScaleKit, 2026](https://www.scalekit.com/blog/saml-vs-oidc)):
```json
{
"iss": "https://idp.example.com",
"sub": "248289761001",
"aud": "your-application-client-id",
"exp": 1780392000,
"iat": 1780388400,
"email": "jane@customer.com"
}
```
The discovery document is what lets an OIDC client configure itself without a manual metadata exchange. A trimmed `/.well-known/openid-configuration` response advertises the endpoints and the signing algorithm the provider supports:
```json
{
"issuer": "https://idp.example.com",
"authorization_endpoint": "https://idp.example.com/authorize",
"token_endpoint": "https://idp.example.com/token",
"jwks_uri": "https://idp.example.com/.well-known/jwks.json",
"id_token_signing_alg_values_supported": ["RS256"]
}
```
## OIDC vs SAML: the head-to-head comparison
Both SAML 2.0 and OIDC are mature, production-grade federation options, and a head-to-head comparison rarely turns on "which is more secure." The differences that decide real builds are token format and transport, platform fit (web, SPA, mobile, machine-to-machine), discovery and operational burden, and governance. Read the matrix below as a fit guide, not a scoreboard: each protocol wins on the surfaces it was designed for.
### At a glance: SAML 2.0 vs OIDC
| Dimension | SAML 2.0 | OIDC |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Token format | XML `` signed with XML-DSig; typically 2-8 KB ([Okta, identity-101](https://www.okta.com/identity-101/whats-the-difference-between-oauth-openid-connect-and-saml/), [ScaleKit, 2026](https://www.scalekit.com/blog/saml-vs-oidc)) | JWT ID token signed with a key from a JWKS endpoint; typically 0.9-1.5 KB ([ScaleKit, 2026](https://www.scalekit.com/blog/saml-vs-oidc)) |
| Transport / bindings | HTTP Redirect (DEFLATE), HTTP POST (signed form), HTTP Artifact (back-channel SOAP) ([OASIS, 2005](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html)) | Authorization Code Flow over HTTPS; PKCE for public clients ([RFC 9700, 2025](https://datatracker.ietf.org/doc/rfc9700/)) |
| Discovery / metadata | Manual metadata exchange (entity ID, certs, endpoints) per connection | `/.well-known/openid-configuration` self-describes the provider ([OpenID Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)) |
| Platform fit | Web SSO strong; SPA awkward; mobile a poor fit; no M2M role | Web, SPA, mobile-native, and M2M all covered |
| Provisioning companion (SCIM) | Paired with SCIM for lifecycle provisioning | Paired with SCIM for lifecycle provisioning |
| Maturity / governance | OASIS Standard since 2005; deep gov/edu federation install base | OpenID Foundation; ISO/IEC 26131:2024; OpenID Federation 1.0 finalized Feb 2026 |
| Typical use | Legacy enterprise IdPs, government, higher education, regulated sectors | New builds, consumer and B2B apps, mobile, APIs, AI agents |
| Operational burden (cert rotation) | Signing certs expire in 1-3 years and need coordinated SP-IdP rollover ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on)) | JWKS keys auto-rotate; clients refetch the published key set |
Verdict: for a new application, OIDC is the lower-friction default; SAML remains required wherever a customer's IdP or a compliance regime depends on it, so the durable answer for B2B is a provider that speaks both.
### Architecture and protocol mechanics
The protocols diverge most in how they package and verify identity.
SAML carries identity in an XML document. The IdP returns a `` containing a ``, and integrity rests on an embedded `` computed with XML Digital Signature over a canonicalized (C14N) form of the XML. Verifying it means canonicalizing the same subtree, checking the digest, and validating the certificate. That XML pipeline is the source of both SAML's verbosity and its sharpest attack surface (more on that below).
OIDC carries identity in a JWT. The ID token is three base64url segments (header, claims, signature), and the required claims are compact: `iss`, `sub`, `aud`, `exp`, `iat` ([OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)). Verification fetches the provider's public keys from its `jwks_uri` and checks one signature, usually `RS256`. A decoded payload is small and human-readable:
```json
{
"iss": "https://idp.example.com",
"sub": "248289761001",
"aud": "your-client-id",
"exp": 1893456000,
"iat": 1893452400,
"email": "ada@customer.com"
}
```
Transport differs too. SAML moves assertions through browser bindings: HTTP Redirect (DEFLATE-compressed), HTTP POST (a signed, base64-encoded form), or HTTP Artifact, which keeps the assertion off the browser via a back-channel SOAP exchange ([OASIS, 2005](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html)). OIDC uses the OAuth 2.0 Authorization Code Flow, with tokens delivered from the token endpoint rather than the front channel, and PKCE binding the `code_challenge` to the request for public clients ([RFC 9700, 2025](https://datatracker.ietf.org/doc/rfc9700/)).
Onboarding a connection differs in effort. SAML needs a manual metadata exchange per IdP: entity IDs, ACS URLs, and X.509 certificates copied between the service provider and the identity provider. OIDC providers publish a discovery document at `/.well-known/openid-configuration` that advertises their endpoints and signing algorithms, so a client can configure itself with far less hand-wiring ([OpenID Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)).
### Platform and device fit
This is where the two protocols genuinely separate, and the differences are about engineering constraints, not preference.
| Surface | SAML 2.0 | OIDC | Why |
| --------------------- | -------------------------- | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Web (server-rendered) | Yes | Yes | Browser redirect/POST bindings and the Authorization Code Flow both fit a server-side web app cleanly. |
| SPA (browser-only) | Awkward | Yes | OIDC with Authorization Code + PKCE is built for browser clients. SAML's signed-XML model fits SPAs poorly; if a customer IdP only speaks SAML, brokering SAML into an OIDC session is the common fix. |
| Mobile / native | Poor fit / workaround-only | Yes | OIDC via RFC 8252 / AppAuth is the standards-body default for native apps ([RFC 8252, 2017](https://datatracker.ietf.org/doc/html/rfc8252); [AppAuth](https://appauth.io/)). SAML has no standards-body native SDK, and signing keys can't live safely in a mobile or JS client. It isn't strictly impossible: a provider can complete SAML SSO in a native app through allowlisted redirect URLs (for example, Clerk's [Native applications support](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)) or by brokering the customer's SAML IdP into an OIDC app session. |
| M2M / API / AI agent | No | Yes | Non-human callers use the OAuth 2.0 workload layer: client-credentials, RFC 8693 token exchange, and OIDC-style JWTs. SAML has no role in machine-to-machine flows. |
A few of these deserve a sentence of context.
For SPAs and native apps, the protocol-level argument against SAML is well documented: SAML can't safely hold signing material in a browser or mobile runtime, and it has no native-app metadata or SDK story ([IdentityServer](https://www.identityserver.com/articles/why-you-wouldn-t-use-saml-in-a-spa-and-mobile-app)). That source calls SAML close to unusable for native apps. The practical reality is a bit softer: providers do complete SAML logins on these surfaces by brokering to OIDC or using allowlisted redirects, so treat SAML here as a poor fit you route around rather than a hard wall.
For machine-to-machine and AI-agent traffic, the distinction is cleaner. Interactive SAML and OIDC user-login flows don't apply to a non-human caller, but OAuth 2.0 and the JWTs layered on it very much do. That workload layer (client-credentials grants, RFC 8693 token exchange, OIDC-style assertions) is where agent and service identity lives, and SAML simply has no part in it.
### SAML vs OIDC security comparison
This is the summary; the deep CVE and case-study treatment lives in the risk section later. At the level of attack classes, the two protocols fail differently.
SAML's risks cluster around its XML core: XML Signature Wrapping (a signed node and the processed node end up in different positions), canonicalization tricks (C14N normalizes or strips content so a forged value still passes the signature check), and parser-differential bypasses (two XML parsers disagree, so the signature is checked on one tree while identity is read from another). OIDC and JWT risks cluster around token handling: algorithm confusion (swapping `RS256` to `HS256` and signing with the server's public key), libraries that honor `alg:none` and treat a forged token as unsigned, and PKCE-downgrade attacks that strip `code_challenge` to skip the binding.
The honest verdict: protocol-structural risk favors OIDC for new builds because SAML's XML canonicalization and parser-differential surface produced a disproportionate run of high-to-critical, actively-exploited bypasses in 2024-2026, but provider quality and implementation hygiene dominate real-world outcomes, and NIST SP 800-63C-4 recognizes both as valid at every assurance level ([NIST SP 800-63C-4, 2025](https://csrc.nist.gov/pubs/sp/800/63/c/4/final)).
> A higher count of headline SAML CVEs reflects SAML's complex XML attack surface and its long install base, not a verdict that SAML deployments are unsafe. A well-maintained SAML connection from a quality provider is a sound choice; the risk section breaks down the specific attack classes and their representative CVEs.
### Developer experience and ecosystem
Day-to-day, OIDC is the easier protocol to build and debug, while SAML carries deeper enterprise reach.
Tooling shows the gap plainly. A JWT decodes instantly in the browser at jwt.io with no setup, so inspecting an OIDC token is a paste-and-read operation. A SAML response needs schema-aware tooling like samltool.com to base64-decode, inflate, and validate the signature against the IdP's certificate ([SAMLTool](https://www.samltool.com/)). Both protocols have mature, widely-used libraries across major languages, and the long history of SAML XML-parsing bugs is a reminder to keep those libraries current rather than a reason to avoid the protocol.
Coverage is where SAML still earns its place. Essentially every enterprise and government IdP speaks SAML 2.0, and large federations in higher education and the public sector are built on it. OIDC coverage is now broad among modern IdPs and is gaining federation tooling of its own (OpenID Federation 1.0 was finalized in February 2026), but a B2B product selling upmarket will still meet customers whose only option is SAML. That coverage reality, more than any protocol feature, is why the pragmatic build supports both.
## Total cost of ownership: the factor most comparisons hide
SAML and OIDC are at functional parity for enterprise SSO, so the real decision is economic and operational. The costs that move the number are the provider's pricing model (per-connection vs per-MAU), the customer IdP's own licensing, the "SSO tax," SMS and MFA add-ons, certificate and metadata maintenance, compliance overhead, and lock-in. Most comparisons stop at the protocol diagram and skip every one of these. This section makes them explicit and gives you a model you can populate.
### Why TCO is the real differentiator
Protocol choice barely moves the bill. Both SAML 2.0 and OIDC ship in every serious provider, both clear every assurance level in [NIST SP 800-63C-4, 2025](https://csrc.nist.gov/pubs/sp/800/63/c/4/final), and a competent provider abstracts the wire format away. Once parity holds, the decision stops being "which protocol" and becomes "which provider, on which pricing model, with which operational tail."
That tail is where the surprises live. Two providers can quote the same headline price and diverge by 5x once you add the customer's IdP licensing, the per-connection or per-MAU curve at your actual scale, certificate rotation labor, and the compliance evidence your buyers' security reviews demand. The protocol is a checkbox. The cost structure is the decision.
### Provider and direct costs: per-MAU vs per-connection
Two pricing models dominate, and they diverge hard as you move upmarket. Per-MAU bills on monthly active users across your whole base. Per-connection bills per enterprise SSO link you stand up. An "enterprise connection" is one configured federation between your app and a single customer's IdP.
Here's the B2B logic that makes the models split. One enterprise customer is effectively one enterprise connection, no matter how many seats sit behind it. A customer with 50 employees and a customer with 50,000 employees each consume one connection. So per-connection cost tracks your number of enterprise customers, while per-MAU cost tracks total seats. As you sell into larger enterprises, per-MAU climbs with every seat you onboard, but per-connection stays flat per customer. That makes per-connection more predictable when your growth is "more big customers" rather than "more total users."
Most B2B providers cluster their per-connection price in the $50 to $150 range, often with volume tiers that drop as connection count rises:
| Provider | Model | Headline price |
| --------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| WorkOS | Per-connection | $125/connection (1-15), dropping to $50 (101-200) ([WorkOS Pricing](https://workos.com/pricing)) |
| Auth0 | Per-MAU + connection cap | B2B Essentials $150/mo for 3 connections, +$100 each, max 30 ([Auth0 Pricing](https://auth0.com/pricing)) |
| Okta | Per-user | $6-$17/user/mo + $1,500 annual minimum ([Okta Pricing](https://www.okta.com/pricing/)) |
| Microsoft Entra | Per-user | P1 $6/user/mo, P2 $9/user/mo ([Microsoft Entra Pricing](https://www.microsoft.com/en-us/security/business/microsoft-entra-pricing)) |
| Ping Identity | Per-user | $3/user/mo, 5,000-user minimum ([Ping Identity Pricing](https://www.pingidentity.com/en/platform/pricing.html)) |
| PropelAuth | Flat | $150/mo, unlimited connections ([PropelAuth Pricing](https://www.propelauth.com/pricing)) |
| Frontegg | PAYG | Free tier, then custom ([Frontegg Pricing](https://frontegg.com/pricing)) |
| Clerk | Per-connection (1 included) | First connection included, then $75 (2-15), $60 (16-100), $30 (101-500), $15 (500+) ([Clerk Pricing](https://clerk.com/pricing)) |
The numbers above are headline rates as of mid-2026; verify against each vendor's pricing page before you model, since tiers change.
### Identity provider and licensing costs
The provider invoice is only half the bill. The customer's own IdP imposes its own cost, and per-feature licensing tiers decide how much.
Microsoft Entra is the common case. The free tier covers SSO for a limited set of apps, but conditional access and SCIM provisioning sit in P1 at $6/user/mo, and identity governance lives in P2 at $9/user/mo ([Microsoft Entra Pricing](https://www.microsoft.com/en-us/security/business/microsoft-entra-pricing)). Okta stacks the same way: a $6 to $17/user/mo base plus a $1,500 annual minimum, with lifecycle management and governance as separate add-ons ([Okta Pricing](https://www.okta.com/pricing/)). The features an enterprise buyer needs for a real rollout usually live a tier or two above the entry price.
Then there's the connection cliff. Auth0's B2B plans cap SSO at 30 connections: Essentials starts at $150/mo for 3 connections and adds $100 for each additional one, but the door closes at 30 ([Auth0 Pricing](https://auth0.com/pricing)). For a B2B app whose growth is measured in enterprise customers, a 30-connection ceiling is a hard TCO cliff. Customer 31 forces a tier jump or a re-platform, and you hit it precisely when the business is working.
### The "SSO tax"
Many vendors gate SSO behind their most expensive enterprise tier, charging a steep premium for a feature that costs them little to ship. The community tracks it on [sso.tax](https://sso.tax/), and the markups get absurd:
| Vendor | SSO markup | Source |
| -------- | ----------------------- | ----------------------------------------------------------------- |
| Railway | \~9,900% | [sso.tax](https://sso.tax/) |
| Appsmith | \~16,567% | [sso.tax](https://sso.tax/) |
| Mixpanel | \~4,065% | [sso.tax](https://sso.tax/) |
| GitHub | $4 to $21/user (\~425%) | [AccessOwl](https://www.accessowl.com/blog/your-guide-to-sso-tax) |
| HubSpot | +$2,800/mo | [AccessOwl](https://www.accessowl.com/blog/your-guide-to-sso-tax) |
A nuance worth pinning down: the SSO tax applies to enterprise SSO broadly, SAML or OIDC. SAML gets gated more often because requesting it signals a buyer with an enterprise IdP and a procurement budget, while OIDC social logins frequently sit on lower tiers. So the gating tends to follow the buyer profile, not the protocol's mechanics.
It's also a choice, not a law of nature. The "Friends of SSO" list catalogs vendors that include SSO at no surcharge ([ssotax.org](https://ssotax.org/friends-of-sso.html)), which proves the premium is a pricing decision rather than a cost-recovery necessity. As a low-key contrast, Clerk includes the first enterprise connection and meters additional ones ([Clerk Pricing](https://clerk.com/pricing)), so SSO isn't walled off behind a separate enterprise SKU.
> When you model the SSO tax, count it on both sides: the per-app premium you pay vendors in your own stack, and the premium your customers would pay if you gated SSO in your product. Gating it can win short-term revenue and lose security-conscious enterprise deals.
### SMS, MFA, and add-on fees
Second factors carry their own line items. SMS-based factors add a per-message cost, and some providers charge a separate per-user MFA license on top of the base plan. Both compound at scale, and both are easy to leave out of an early estimate.
Clerk is transparent here: it passes SMS through at about $0.01/SMS for US and Canada (market rate internationally), and there's no separate MFA license fee ([Clerk Pricing](https://clerk.com/pricing)). To be clear, Clerk's SMS is billed, not free. It's a metered pass-through of the carrier cost rather than a marked-up add-on. TOTP and backup-code factors don't carry a per-message charge, so the SMS line only applies when you actually send SMS.
### Operational and risk costs
The bill keeps running after launch. Four operational costs recur, and one of them is a clean protocol-level differentiator.
Implementation time comes first. Standing up enterprise SSO against real customer IdPs takes engineering hours up front, and there's an ongoing maintenance tail for every connection you support. (Build cost is real and larger than most teams expect; the build-vs-buy dollar model belongs to the implementation section, so treat it here as a line item that exists, not one to itemize.)
SAML certificate rotation is the differentiator. SAML signing certificates expire, typically on a 1-to-3-year cycle, and renewing one requires a coordinated rollover between the service provider and the identity provider: stage the new certificate, sync metadata on both sides, and cut over inside an overlap window. Entra doesn't auto-propagate a renewal to connected SPs, so a missed expiry is one of the most common ways enterprise SSO breaks ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on); [ScaleKit](https://www.scalekit.com/blog/saml-certificates-the-hidden-reason-enterprise-sso-breaks)). OIDC sidesteps the whole ritual. Keys publish at a JWKS endpoint and rotate at the protocol level, so clients fetch current keys automatically with no coordinated SP-IdP maintenance window ([OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)). That's a real, recurring operational cost SAML carries and OIDC doesn't.
Compliance overhead is the third. The audit evidence enterprise buyers demand has a price: a SOC 2 Type II commonly runs $20k to $60k in the first year for a startup once audit fees, compliance tooling, and internal effort are counted, with lower ongoing maintenance after that ([Sprinto](https://sprinto.com/blog/soc-2-compliance-cost/)). A managed provider that already holds the attestation folds that cost into its subscription instead of leaving it on your books.
Infrastructure and hosting is the fourth. A managed provider adds $0 in extra infrastructure: there are no servers to run for the auth layer. A self-hosted baseline like Keycloak or Authentik is free in license terms but carries the compute, on-call, patching, and upgrade burden of running an identity service yourself. "Free" open source is a staffing cost, not a zero.
### Vendor lock-in cost
Lock-in is the cost you pay at the exit, and it's easy to ignore until you need to leave. Three things drive it. Migration friction: moving enterprise connections, user records, and session infrastructure to a new provider is a project, not a config change. Proprietary extensions: features built on a vendor's non-standard APIs or custom claim shapes don't port cleanly to a competitor. Data portability: how cleanly you can export users, organizations, and connection metadata in a usable format determines how trapped you are.
Standards-based protocols soften the blow. SAML and OIDC are interoperable by design, so a provider that exposes clean federation and a real export path is cheaper to leave than one that wraps everything in proprietary glue. Weigh portability before you commit, not when you're already trying to get out.
### A reusable TCO framework
Use this checklist to make sure every cost is on the table. Skipping any one of the nine is how a comparison ends up off by multiples.
- [ ] Provider and direct costs (per-MAU vs per-connection, at your real scale)
- [ ] Identity provider and licensing (the customer's own IdP tier and feature add-ons)
- [ ] SSO tax (premium you pay vendors, and any you'd charge customers)
- [ ] SMS and MFA add-ons (per-message SMS, per-user MFA licensing)
- [ ] Implementation time (up-front engineering to integrate)
- [ ] Ongoing maintenance (per-connection support, cert rotation labor)
- [ ] Compliance (SOC 2 and other attestations your buyers require)
- [ ] Infrastructure and hosting ($0 managed vs self-hosted compute and on-call)
- [ ] Vendor lock-in (migration friction, proprietary extensions, data portability)
Then populate a worked model. The table below is a skeleton, not a quote: every dollar figure is a placeholder you fill with current vendor numbers for your own seat count and connection count. Its job is to show how the models diverge as you scale, not to hand you a total.
| TCO component | Scenario A: early B2B (10 connections / 50k MAU) | Scenario B: scale-up (60 connections / 200k MAU) | Scenario C: regulated (200 connections + SCIM + audit logs) |
| ------------------------------ | ------------------------------------------------ | ---------------------------------------------------------------- | ----------------------------------------------------------- |
| Provider, per-connection model | connections × tier rate (illustrative) | connections × tier rate, volume discount kicks in (illustrative) | connections × lowest tier rate (illustrative) |
| Provider, per-MAU model | MAU × per-MAU rate (illustrative) | MAU × per-MAU rate, climbs with seats (illustrative) | MAU × per-MAU rate, highest here (illustrative) |
| Auth0 30-connection cap | within cap | exceeds 30-connection cap: re-tier or re-platform (illustrative) | far beyond cap: not viable on B2B plan (illustrative) |
| Customer IdP licensing | included in customer budget | included in customer budget | included in customer budget |
| SCIM provisioning | optional | recommended | required (illustrative) |
| Compliance (SOC 2 etc.) | may defer | likely required | required, ongoing (illustrative) |
| Infrastructure | $0 managed / self-host baseline | $0 managed / self-host baseline | $0 managed / self-host baseline |
Read the first two rows together. In Scenario A both models are cheap and close. By Scenario B, the per-MAU figure has climbed with every seat while the per-connection figure rose only with customer count and started catching volume discounts, so the gap opens. By Scenario C the per-MAU model is carrying its full seat load while the per-connection model sits on its lowest tier. The Auth0 row is the other lesson: a 30-connection cap is fine in Scenario A and a blocker by Scenario B, which is exactly when the business is growing fastest. Fill the cells with live numbers and the right model for your trajectory falls out on its own.
## A risk assessment framework for SSO protocol and provider choice
Treat protocol risk and provider risk as separate axes. At the protocol layer both SAML and OIDC have had critical, exploited vulnerabilities; SAML's XML attack surface has produced a larger, more structural run of bypasses in 2024-2026, but real-world safety is dominated by implementation quality, disclosure and remediation discipline, and operational controls. NIST recognizes both protocols as valid at every assurance level ([NIST SP 800-63C-4, 2025](https://csrc.nist.gov/pubs/sp/800/63/c/4/final)).
So score two things, not one: the protocol you adopt, and the provider you trust to implement it. The rest of this section gives an agent the dimensions, the evidence, and a weighted matrix to do that scoring honestly.
### Security risk dimensions: protocol, configuration, tokens, sessions
Four dimensions cover most of the real exposure.
1. Protocol risks. The attack classes baked into how each protocol verifies identity: XML Signature Wrapping, canonicalization tricks, and parser differentials on the SAML side; algorithm confusion, `alg:none`, and PKCE downgrade on the OIDC/JWT side.
2. Configuration risks. Most production breaks are misconfiguration, not protocol math. SAML examples: skipping `InResponseTo` validation, accepting unsigned assertions, or leaving signature verification optional. OIDC examples: loose `redirect_uri` matching, missing `nonce` checks, or not enforcing PKCE.
3. Token and assertion handling. How signed material is validated and stored: rejecting attacker-controlled `alg` selection, pinning the expected issuer and audience, and keeping tokens out of URLs and logs.
4. Session and logout. SAML Single Logout (SLO) is widely unreliable, because it fails when any one service provider in the federation is unresponsive, so stale sessions linger ([IdentityServer, SLO](https://www.identityserver.com/articles/the-challenge-of-building-saml-single-logout)). IdP-initiated SAML compounds this: an unsolicited `SAMLResponse` carries no `InResponseTo`, so the SP loses the binding it needs to detect a replayed or injected assertion ([Scott Brady, SAML](https://www.scottbrady.io/saml/dangers-of-idp-initiated-sso)). That is the same IdP-initiated weakness defined in the primer, now read as a risk.
### Attack classes at a glance
This table maps each attack class to one or two representative CVEs. It is a comparison aid, not a CVE catalog. Scores lead with the NVD v3.1 base score where NVD scored the CVE independently and parenthesize the CNA v4.0 score where it differs; CVEs that NVD has not scored carry the CNA/vendor score labeled "CNA."
| Attack class | Protocol | What it exploits | Representative CVE(s) |
| ------------------------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Parser differential | SAML | Two XML parsers disagree, so the signature is checked on one tree and identity is read from another | CVE-2025-25291/25292 (9.8 NVD v3.1; 9.3 CNA v4.0) |
| Canonicalization / comment injection | SAML | C14N normalizes or strips content so a forged value still passes the signature check | [CVE-2017-11427](https://nvd.nist.gov/vuln/detail/CVE-2017-11427) (9.8 NVD v3.0); CVE-2025-66568 (9.1 NVD v3.1; 9.3 CNA v4.0) |
| XML Signature Wrapping (XSW) | SAML | Signed node and processed node sit in different positions, so the signature is valid but the data is attacker-controlled | CVE-2024-45409 (9.8 NVD v3.1); [CVE-2020-5390](https://nvd.nist.gov/vuln/detail/CVE-2020-5390) (7.5 NVD v3.1, PySAML2) |
| Assertion injection | SAML | An unsigned malicious assertion is prepended before a legitimately signed one | CVE-2026-25922 (8.8 CNA); [CVE-2026-34840](https://nvd.nist.gov/vuln/detail/CVE-2026-34840) (8.1 CNA) |
| Memory overread to session hijack | SAML | An out-of-bounds read leaks live session material (assertions, cookies); NVD scores full confidentiality, integrity, and availability because the leak enables takeover, not disclosure alone | CVE-2026-3055 (9.8 NVD v3.1; 9.3 CNA v4.0; CISA KEV, exploited in the wild) |
| DoS via malformed SAML | SAML | A crafted SAML message reloads or crashes the device (availability only) | [CVE-2026-20101](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-saml-LktTrwZP) (8.6 CNA, DoS-only) |
| Algorithm confusion (RS256 to HS256) | OIDC/JWT | The `alg` header is swapped to HMAC and signed with the server's RSA public key | [CVE-2015-9235](https://nvd.nist.gov/vuln/detail/CVE-2015-9235) (9.8 NVD v3.0); [CVE-2016-10555](https://nvd.nist.gov/vuln/detail/CVE-2016-10555) (6.5 NVD v3.0) ([PortSwigger Academy](https://portswigger.net/web-security/jwt/algorithm-confusion)) |
| `alg:none` | OIDC/JWT | A library honors `"alg":"none"` and treats a forged token as unsigned | illustrative ([Auth0 JWT-library disclosure](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/)) |
| PKCE downgrade | OIDC | Dropping `code_challenge` or `code_verifier` skips PKCE verification | [CVE-2024-23647](https://nvd.nist.gov/vuln/detail/CVE-2024-23647) (8.8 NVD v3.1; 6.5 CNA) |
| Open redirect | OIDC | Loose redirect-URI validation leaks codes or tokens | [CVE-2023-6927](https://nvd.nist.gov/vuln/detail/CVE-2023-6927) (6.1 NVD v3.1, Medium, illustrative) |
| Cross-tenant token | OIDC/JWT | A token minted in an attacker tenant is accepted in a victim tenant | CVE-2025-55241 (9.8 NVD v3.1; 10.0 Microsoft; clean server-side fix, no exploitation) |
Both protocols ship critical CVEs. The SAML cluster is larger and more structural, because the attacks target XML signature processing itself rather than a single library bug, and they recur across ecosystems. The OIDC counterpoint, CVE-2025-55241 in Microsoft Entra, shows the other half of the picture: even a hyperscaler ships a maximum-severity CVE, and the differentiator is that it was fixed server-side with no customer action and no evidence of exploitation ([Microsoft MSRC, 2025](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55241); [NVD CVE-2025-55241](https://nvd.nist.gov/vuln/detail/CVE-2025-55241)).
### Case studies
Three incidents show what the table compresses: a structural SAML chain, a SAML flaw exploited in the wild, and a clean OIDC remediation.
The Ruby-SAML "Fragile Lock" chain is the structural one. CVE-2024-45409 (9.8 NVD v3.1) was an XPath bug that let a forged `DigestValue` pass signature verification ([NVD CVE-2024-45409](https://nvd.nist.gov/vuln/detail/cve-2024-45409)). The March 2025 patch was followed by CVE-2025-25291 and CVE-2025-25292 (9.8 NVD v3.1; 9.3 CNA v4.0), a parser differential between the REXML and Nokogiri parsers ([GitHub Security Lab, 2025](https://github.blog/security/sign-in-as-anyone-bypassing-saml-sso-authentication-with-parser-differentials/)). Then at Black Hat Europe in December 2025, researcher Zakhar Fedotkin disclosed a fresh cluster of ruby-saml bypasses, CVE-2025-66567 and CVE-2025-66568, both 9.1 NVD v3.1 (9.3 CNA v4.0), via attribute pollution, namespace confusion, and void canonicalization, defeating even previously patched versions ([PortSwigger, 2025](https://portswigger.net/research/the-fragile-lock)). Fedotkin's own assessment, which this guide reports rather than endorses, is that absent a foundational restructuring of SAML libraries, "SAML authentication will remain vulnerable to the same classes of attacks that have persisted for nearly two decades" ([PortSwigger, 2025](https://portswigger.net/research/the-fragile-lock)).
CVE-2026-3055 in Citrix NetScaler is the one attackers actually used. Citrix describes it as a memory overread from insufficient input validation, exploitable only when the appliance is configured as a SAML IdP ([Citrix CTX696300](https://support.citrix.com/external/article/CTX696300/netscaler-adc-and-netscaler-gateway-secu.html)). A malformed request to its `/saml/login` endpoint triggers an out-of-bounds read that returns leftover process memory to the attacker, base64-encoded in the `NSC_TASS` cookie, which can expose session material and enable session hijack ([watchTowr, 2026](https://labs.watchtowr.com/the-sequels-are-never-as-good-but-were-still-in-pain-citrix-netscaler-cve-2026-3055-memory-overread/)). It scores 9.8 NVD v3.1 (9.3 CNA v4.0), and CISA added it to the Known Exploited Vulnerabilities catalog on March 30, 2026, with active exploitation confirmed ([NVD CVE-2026-3055](https://nvd.nist.gov/vuln/detail/CVE-2026-3055)).
CVE-2025-55241 in Microsoft Entra is the clean OIDC counterpoint. A cross-tenant flaw let actor tokens minted in an attacker's tenant be accepted by the legacy Azure AD Graph API in any other tenant, with no pre-existing access required, scored 9.8 NVD v3.1 (10.0 Microsoft). Microsoft mitigated it server-side on July 17, 2025 before CVE assignment, with no customer action required, and reported no detected abuse ([Microsoft MSRC, 2025](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55241); [Dirk-jan Mollema, 2025](https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/)).
### Provider security track record
Weigh impact and disclosure quality over raw CVE counts. A vendor with more published CVEs and fast, candid disclosure is often safer than a quiet one. Two axes matter: how accurately the vendor scoped impact, and how quickly customers were protected.
Okta's 2023 support-system breach is the scoping case. Attackers used stolen credentials to reach Okta's support case-management system and HAR files containing session tokens. Okta revised its impact estimate from 134 customers to all support-system users about six weeks after initial disclosure ([Okta Security, 2023](https://sec.okta.com/articles/2023/11/unauthorized-access-oktas-support-case-management-system-root-cause/)). Three customers, 1Password, Cloudflare, and BeyondTrust, independently detected the anomalous activity and reported it before Okta's own disclosure; Cloudflare says it contacted Okta about the breach before Okta notified Cloudflare, and that BeyondTrust first flagged it to Okta on October 2, 2023 ([Cloudflare, 2023](https://blog.cloudflare.com/how-cloudflare-mitigated-yet-another-okta-compromise/); [1Password, 2023](https://1password.com/blog/okta-incident)). In the earlier 2022 Lapsus$ incident, Okta first put the maximum potential impact at 366 customers, and its final investigation concluded the threat actor had actually accessed 2 ([Okta, 2022](https://www.okta.com/blog/company-and-culture/oktas-investigation-of-the-january-2022-compromise/); [Okta, 2022](https://www.okta.com/blog/company-and-culture/okta-concludes-its-investigation-into-the-january-2022-compromise/)). In 2022, Auth0 disclosed that source-code repositories from October 2020 and earlier had likely been copied, with no platform compromise and no customer data accessed, after an external party notified the company ([Auth0, 2022](https://auth0.com/blog/auth0-code-repository-archives-from-2020-and-earlier/)). Microsoft Entra's CVE-2025-55241 sits at the other end: a maximum-severity flaw fixed server-side with no customer action and no exploitation. Readers can weigh these themselves.
Clerk is a short, positive example of disclosure process. CVE-2024-22206, an IDOR in `auth()` and `getAuth()`, was scored 9.8 (NVD v3.1) and 9.0 (CNA). Clerk found it during an internal code audit on January 9, 2024, contacted Cloudflare, Netlify, and Vercel the same day to coordinate network-layer mitigation, and shipped the patch in `@clerk/nextjs` 4.29.3 about three days later, before public disclosure ([NVD CVE-2024-22206](https://nvd.nist.gov/vuln/detail/CVE-2024-22206)). The no-confirmed-compromise statement attaches only to this CVE: the January 12, 2024 changelog says "while we are not aware of any exploit, we unfortunately cannot be sure without access to the server's logs" ([Clerk Changelog, Jan 12 2024](https://clerk.com/changelog/2024-01-12.md)), and the February 2, 2024 post-mortem says "no customers have reported evidence of an exploit" ([Clerk Changelog, Feb 2 2024](https://clerk.com/changelog/2024-02-02.md)). Clerk has disclosed later CVEs the same way, including [CVE-2025-53548](https://clerk.com/changelog/2025-07-09-cve-2025-53548.md) in `verifyWebhook()` (7.5) and a 2026 trio: CVE-2026-41248 (`createRouteMatcher` bypass, 9.1 CNA), [CVE-2026-42349](https://nvd.nist.gov/vuln/detail/CVE-2026-42349) (`has()` and `auth.protect()` bypass, 8.1 NVD v3.1; 7.6 CNA v4.0), and [CVE-2026-34076](https://advisories.gitlab.com/pkg/npm/@clerk/express/CVE-2026-34076/) (SSRF via the opt-in `clerkFrontendApiProxy`, 7.4 CNA). The no-compromise claim does not extend to those; CVE-2026-41248 carries only a scope statement that sessions are not compromised and no existing user can be impersonated, only the middleware-level gating decision is bypassed ([NVD CVE-2026-41248](https://nvd.nist.gov/vuln/detail/CVE-2026-41248)). None of Clerk's CVEs are on the CISA KEV catalog. Clerk publishes a formal [vulnerability disclosure policy](https://clerk.com/docs/security/vulnerability-disclosure-policy.md).
### Compliance and regulatory risk
Compliance risk is mostly about evidence, not protocol. Buyers' security reviews want SOC 2 Type II and ISO 27001 reports, and regulated buyers add HIPAA (healthcare) and FedRAMP (US federal). Data residency, where identity data is stored and processed, is a separate constraint that can rule a provider in or out regardless of protocol.
On assurance, NIST SP 800-63C-4 defines three Federation Assurance Levels and recognizes both SAML assertions and OIDC ID tokens as valid at FAL1, FAL2, and FAL3. NIST expresses no preference between the protocols ([NIST SP 800-63C-4, 2025](https://csrc.nist.gov/pubs/sp/800/63/c/4/final)). FAL2 adds audience restriction to a single relying party and stronger protection against assertion injection; FAL3 requires cryptographic proof of possession (a holder-of-key assertion or a bound authenticator). Both protocols can meet each level.
For forgery specifically, NIST IR 8587, "Protecting Tokens and Assertions from Forgery, Theft, and Misuse," gives protocol-agnostic guidance. As of June 2026 it is a draft (its public comment period closed January 30, 2026), so treat it as direction rather than a final control ([NIST IR 8587, 2026](https://csrc.nist.gov/pubs/ir/8587/ipd)).
### Continuity and reliability risk
Provider availability is a legitimate risk dimension, and the honest way to assess it is the vendor's own published postmortems, official status pages, and (for Microsoft) PIRs by tracking ID. Status-aggregator "durations" mix open-to-resolved spans and scheduled maintenance, so they are not cited here. Treat a willingness to publish a candid postmortem as a maturity signal, and protocol breadth as a hedge against any single provider's bad day.
1. Clerk publishes detailed postmortems: a 45-minute GCP Cloud Run incident on June 26, 2025 ([Clerk, 2025](https://clerk.com/blog/postmortem-jun-26-2025-service-outage.md)); a Postgres auto-upgrade incident in September 2025 ([Clerk, 2025](https://clerk.com/blog/2025-09-18-database-incident-postmortem.md)); a DNS outage on February 10, 2026 lasting 2h32m with under 5% of API volume impacted ([Clerk, 2026](https://clerk.com/blog/2026-02-10-dns-outage-postmortem.md)); a roughly 90-minute database query-plan incident on February 19, 2026 ([Clerk, 2026](https://clerk.com/blog/2026-02-19-system-outage-postmortem.md)); and a 26-minute Cloud SQL live-migration incident on March 10, 2026 ([Clerk, 2026](https://clerk.com/blog/2026-03-10-service-outage-postmortem.md)). After the September 2025 incident Clerk isolated the Session API onto its own service with read-replica failover ([Clerk Changelog, 2025](https://clerk.com/changelog/2025-09-25-infra-changelog.md)).
2. WorkOS publishes postmortems too: an AuthKit outage on October 20-21, 2025 tied to an AWS us-east-1 disruption ([WorkOS, 2025](https://workos.com/blog/service-disruption-on-october-20-2025)), and the SAMLStorm disclosure in March 2025 (CVE-2025-29774/29775) where WorkOS detected, patched, and disclosed an xml-crypto signature bypass ([WorkOS, 2025](https://workos.com/blog/samlstorm)).
3. Microsoft Entra and Azure carry the largest blast radius. An Azure Front Door outage on October 29-30, 2025 ran several hours globally and cascaded into Entra sign-in (PIR Tracking ID YKYN-BWZ, [Azure status](https://azure.status.microsoft)); an Azure Central US outage on July 18-19, 2024 was a separate event from the same-week CrowdStrike incident; the cleanest pure-Entra availability incident was a Seamless-SSO DNS issue on February 25, 2025.
4. Okta had no major global authentication outage in 2024-2026; its headline event is the 2023 support-system breach above, with a root-cause writeup at [Okta Security](https://sec.okta.com/articles/2023/11/unauthorized-access-oktas-support-case-management-system-root-cause/).
5. Auth0 publishes RCA documents on its status page ([Auth0 status](https://status.auth0.com); verify exact durations there rather than via aggregators).
6. Ping, PropelAuth, and Frontegg: no major public postmortem found as of June 2026. That is a gap in public evidence, not a clean bill of health.
### A risk-scoring matrix
An agent can score a candidate provider and protocol across five dimensions, each rated low, medium, or high, then weight by what the deployment actually demands. The weights below are a starting point; raise compliance weight for regulated buyers, or reliability weight for a high-availability product.
| Dimension | Suggested weight | Low risk | Medium risk | High risk |
| ---------------------------------- | ---------------- | ------------------------------------------------------------------------------ | ----------------------------------------------- | ------------------------------------------------------------------------------------- |
| Protocol attack surface | 20% | OIDC with PKCE and exact redirect matching | OIDC with legacy flows, or well-maintained SAML | SAML on an unmaintained XML library, or any unsigned-assertion config |
| Configuration and operational risk | 25% | Managed provider, signature verification enforced, short assertion validity | Self-hosted with current patches and monitoring | Manual cert handling, optional signature checks, IdP-initiated without short validity |
| Provider disclosure quality | 20% | Public CVEs, fast patches, accurate scoping, coordinated mitigation | CVEs disclosed but slow or vaguely scoped | No public CVE history or disclosure policy |
| Reliability and continuity | 20% | Candid postmortems, documented resiliency fixes, multi-protocol breadth | Status page only, limited postmortems | No public incident record and single-protocol lock-in |
| Compliance fit | 15% | SOC 2 + ISO 27001 + the buyer's required regime (HIPAA/FedRAMP), residency met | Core attestations present, some gaps | Missing a required attestation or residency option |
Score each dimension, multiply by its weight, and the candidate with the lower weighted total is the safer fit for that specific deployment. The point is to make the tradeoff explicit rather than defaulting to "SAML feels old" or "OIDC is newer."
> Golden SAML is scoped to on-premises ADFS, not a generic SAML flaw. The attack requires the attacker to already hold the ADFS token-signing key, after which forged tokens are indistinguishable from legitimate ones. It was first used in the wild in the 2020 SolarWinds campaign ([CyberArk](https://www.cyberark.com/resources/threat-research-blog/golden-saml-revisited-the-solorigate-connection); [CISA AA21-008A](https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-008a)). It does not apply to a managed SAML provider that holds its own signing keys, so do not score it against SAML-as-a-protocol.
## How to choose an SSO protocol: a decision guide
The protocol is usually the last thing to decide, not the first. Which IdPs your customers run, whether you need SCIM offboarding, what audit evidence your buyers' security reviews demand, your pricing model: those choices come first, and the protocol falls out of them. Keep the three layers separate as you read this. Federation is SAML or OIDC, provisioning is SCIM, and the workload/agent layer is OAuth and token exchange. The tree below decides the federation layer only.
### Decision tree
Walk it top to bottom. Start with the surfaces you actually serve, then your customers' IdP estate, then compliance, then cost, then read the outcome.
- **Step 1: What application surface(s) do you serve?**
- **SPA only** then OIDC with Authorization Code + PKCE. If a customer IdP only speaks SAML, broker SAML to OIDC at the provider rather than putting SAML in the browser.
- **Mobile / native** then OIDC + PKCE is the default ([RFC 8252](https://datatracker.ietf.org/doc/html/rfc8252); [AppAuth](https://appauth.io/)). SAML is a poor fit and there's no standards-body native SAML SDK, so treat it as workaround-only: if a SAML-only enterprise IdP is mandatory, broker SAML to OIDC or complete the SAML flow through allowlisted native redirect URLs. Then stop.
- **M2M / API / AI agent** then the OAuth 2.0 family: client-credentials grant, [RFC 8693 token exchange](https://datatracker.ietf.org/doc/html/rfc8693), and OIDC-style JWT assertions, plus workload identity (SPIFFE, IETF WIMSE). Interactive SAML/OIDC user-login flows don't apply to a non-human caller, but OAuth and the JWTs layered on it very much do. SAML has no role here. Then stop.
- **Server-rendered web / enterprise portal** then go to Step 2.
- **Step 2: What IdPs do your enterprise customers run?**
- **Only legacy SAML** (ADFS, Shibboleth, on-prem Ping) then you must support SAML; add OIDC where the customer allows it.
- **Modern IdPs** (Okta, Entra, Google, all of which speak both) then prefer OIDC for new connections; support SAML on request.
- **Government / higher-ed / regulated** then support SAML (FedRAMP and academic federations lean SAML) and OIDC ([Login.gov strongly recommends OIDC](https://developers.login.gov/saml/getting-started/); [SMART on FHIR](https://smarthealthit.org/smart-on-fhir-api/) is OAuth/OIDC).
- **Mixed estate** (the typical B2B reality) then support both.
- **Step 3: What compliance constraints apply?**
- **FedRAMP / FISMA** then both protocols, with FIPS-validated crypto for FAL2 and above.
- **HIPAA** then SAML for EHR federation; OIDC/SMART-on-FHIR for clinical apps.
- **SOC 2 Type II** then SCIM deprovisioning plus a durable audit trail are effectively mandatory. JIT alone fails offboarding controls because it never deactivates an account ([WorkOS, SCIM vs JIT](https://workos.com/blog/scim-vs-jit-what-s-the-difference)).
- **None** then OIDC-first, with SAML for the customers that require it.
- **Step 4: Are you building or buying?**
- **Building** then budget 12 to 16 weeks plus an ongoing cert, metadata, and SCIM maintenance tail (see the implementation section below).
- **Buying** then days to weeks; choose by pricing model (per-connection vs per-MAU), SCIM inclusion, admin/onboarding workflow, and audit/event visibility.
That produces one of five outcomes:
- **Greenfield B2B** then OIDC-first, add SAML before the first enterprise deal, add SCIM, and buy rather than build.
- **Legacy SAML installed base** then dual-run via an identity broker and don't force-migrate.
- **Mobile / SPA / API / agent** then OIDC and OAuth; broker SAML only if a specific customer IdP requires it.
- **Government / healthcare / education** then both protocols, plus SCIM, plus audit.
- **Upmarket push** then ship SAML + OIDC + SCIM as table stakes; don't gate them behind a punitive tier.
### Scenario-based recommendations
Five common situations, the protocols each one calls for, and why. NIST SP 800-63C-4 recognizes both SAML and OIDC at every assurance level ([NIST, 2025](https://csrc.nist.gov/pubs/sp/800/63/c/4/final)), so the "recommended" column reflects platform fit and customer reality, not a security ranking.
| Scenario | Surface | Customer IdP reality | Compliance | Recommended protocol(s) | Provisioning | Why |
| ---------------------------- | --------------------- | -------------------------------------- | --------------------- | ----------------------------------------------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Greenfield / first-time | Web + SPA | None yet | Light | OIDC-first; add SAML before the first enterprise deal | JIT now, SCIM before upmarket | Buy, don't build. OIDC is the cleanest default; SAML becomes a deal-blocker the moment a customer's security review asks for it. |
| SAML-to-OIDC migration | Web | Established SAML | Existing controls | Run both; broker via an identity layer | Keep SCIM running | Expect a stable hybrid rather than a clean cutover. IdPs are becoming protocol translators ([Duende, 2026](https://duendesoftware.com/blog/20260528-saml-and-openid-connect)); don't force-migrate working connections. |
| B2B SaaS going upmarket | Web + SPA | Mixed (Okta, Entra, ADFS) | SOC 2 Type II | SAML + OIDC | SCIM required | These three are table stakes, expected before the first security review, not after the first lost deal. SCIM offboarding is a SOC 2 control JIT can't satisfy. |
| Mobile / SPA / API-first | Native + SPA + M2M | Often none, sometimes one SAML holdout | Varies | OIDC + OAuth (PKCE; client-credentials for M2M) | JIT or SCIM as needed | SAML doesn't fit native or M2M ([RFC 8252](https://datatracker.ietf.org/doc/html/rfc8252)). Broker SAML to OIDC only for the one customer IdP that demands it. |
| Regulated / compliance-heavy | Web (+ clinical apps) | Gov, healthcare, or education | FedRAMP, HIPAA, FISMA | Both + SCIM + audit | SCIM required | FedRAMP and academic federations lean SAML; [Login.gov strongly recommends OIDC](https://developers.login.gov/saml/getting-started/); HIPAA's [SMART on FHIR](https://smarthealthit.org/smart-on-fhir-api/) is OIDC/OAuth. You'll carry both. |
### A decision checklist
Walk this against your own requirements. Each box you check points the recommendation toward supporting both protocols, which is where most B2B teams land.
- [ ] You serve a native or mobile app (OIDC + PKCE; SAML is workaround-only)
- [ ] You have machine-to-machine or AI-agent traffic (OAuth workload layer, not SAML)
- [ ] At least one enterprise customer runs a SAML-only IdP (you must support SAML)
- [ ] Your customers run a mix of Okta, Entra, Google, and legacy IdPs (support both)
- [ ] A buyer's security review will ask for SCIM deprovisioning (add SCIM, not just JIT)
- [ ] You need SOC 2 Type II or HIPAA evidence (durable audit trail + SCIM)
- [ ] You're choosing build vs buy on cost (price per-connection against per-MAU at your real scale)
- [ ] You want to avoid an SSO tax on your own customers (don't gate SSO behind a punitive tier)
## The pragmatic answer: an enterprise SSO solution that supports both SAML and OIDC
For enterprise SSO, pick a provider that supports both SAML and OIDC behind one integration, rather than betting on a single protocol. Enterprises arrive with mixed IdP estates, so a both-protocol provider lets you onboard a SAML-only customer and an OIDC-only customer through the same enterprise-connection model, add SCIM provisioning, and stop treating "SAML or OIDC" as a strategic decision. [Clerk](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md), [WorkOS](https://workos.com/pricing), [Auth0](https://auth0.com/pricing), [PropelAuth](https://www.propelauth.com/pricing), and [Frontegg](https://frontegg.com/pricing) all do this; they differ on pricing model, provisioning, admin workflow, and audit depth.
### What is an enterprise connection?
An enterprise connection (some providers call it an SSO connection) is a single configured trust relationship between your app and one customer's identity provider, over SAML or OIDC. It's scoped to that customer's organization or verified email domain, and it's configured and maintained per-customer, often by the customer's own IT admin through a hosted setup portal.
The pricing consequence is the important part. One enterprise customer equals one connection, no matter how many seats sit behind it: a 50-employee customer and a 50,000-employee customer each consume exactly one connection. So per-connection pricing tracks your number of enterprise customers, while per-MAU pricing tracks total seats. For B2B growth measured in "more big customers," per-connection is the more predictable model. It's a standard term across [Clerk](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md), WorkOS, and Auth0.
### Why supporting both usually wins
Your customers won't standardize on one protocol for you. A large bank might run ADFS over SAML; a fast-growing startup might run Google or Entra and prefer OIDC; a healthcare customer might need SAML for its EHR and OIDC for clinical apps. Support only one and you either turn away the customers on the other, or you build a one-off bridge per deal.
Supporting both removes the protocol bet and shortens sales cycles. When a prospect's security team asks "do you support our IdP," the answer is yes regardless of which protocol they speak, and the connection gets configured instead of escalated to engineering. The protocol becomes an implementation detail the provider absorbs.
### What a both-protocol solution should provide
Use this as your requirements list when you evaluate providers. A solution that covers all of it lets you say yes to enterprise buyers without a custom project each time.
- [ ] SAML and OIDC enterprise connections behind one configuration model
- [ ] Per-customer IdP config (ideally delegable to the customer's IT admin)
- [ ] SCIM provisioning and deprovisioning, not just login-time JIT
- [ ] Predictable pricing (per-connection scales with customers, not seats)
- [ ] Low operational burden (managed cert rotation and metadata, no servers to run)
- [ ] Audit and event visibility your security reviews can point at
### Where Clerk fits
Clerk is a strong fit when you're a React or Next.js B2B SaaS that needs SAML, OIDC, and SCIM fast, at low-to-moderate connection counts, without an SSO tax. Here's what it brings, with each capability linked to its docs.
1. **Both protocols, plus EASIE.** Clerk supports SAML, OIDC, and EASIE enterprise connections through one model ([Clerk, Enterprise SSO](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)), and a custom OIDC provider connects via its discovery endpoint ([Clerk, OIDC custom provider](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/oidc/custom-provider.md)).
2. **SCIM via Directory Sync is GA.** Core Directory Sync reached general availability on April 16 2026, enabled for all users ([Clerk, Directory Sync GA](https://clerk.com/changelog/2026-04-16-directory-sync.md)). Group-to-role and custom attribute mapping reached GA on May 21 2026 ([Clerk, groups and attributes GA](https://clerk.com/changelog/2026-05-21-directory-sync-groups-attributes-ga.md)). It's available across plans, and per the pricing page is included with an enterprise connection at no extra charge ([Clerk Pricing](https://clerk.com/pricing)). When a user is removed or deactivated in the IdP, Clerk deactivates the Clerk user and immediately revokes their active sessions ([Directory Sync docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync.md)).
3. **One unified Backend API.** A single `/enterprise_connections` endpoint covers both SAML and OIDC, with full CRUD; the old SAML-only endpoint is deprecated ([Clerk, unified enterprise connections API](https://clerk.com/changelog/2026-03-09-bapi-enterprise-connections.md)).
4. **Org-level B2B SSO and JIT.** Enterprise SSO binds to organizations ([Clerk, organization-level SSO](https://clerk.com/docs/guides/organizations/add-members/sso.md)), and JIT provisions accounts on first SSO login when you don't need full SCIM ([Clerk, JIT provisioning](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/jit-provisioning.md)).
5. **A modern session model.** After the IdP authenticates a user, Clerk issues its own short-lived session JWT (about 60 seconds), auto-refreshed in the background, and verified networklessly with a local signature check rather than a network round-trip on every request ([Clerk, How Clerk works](https://clerk.com/docs/guides/how-clerk-works/overview.md)). That maps cleanly onto zero-trust's per-request verification.
6. **Transparent security posture.** Clerk publishes its CVEs, a formal [vulnerability disclosure policy](https://clerk.com/docs/security/vulnerability-disclosure-policy.md), and candid incident postmortems (covered evenhandedly in the risk section alongside other providers).
7. **Low-friction starting point.** Development instances include 25 free enterprise connections, and the React/Next.js developer experience is a genuine strength.
> EASIE connections run through a multi-tenant OpenID provider, which raises the risk of tenant crossover relative to a single-tenant IdP. Clerk implements mitigations, but apps that require strict single-tenant isolation should use SAML rather than EASIE ([Clerk, Enterprise SSO](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)).
### Honest caveats
Every strength above has a limit. Name these before you commit, and weigh them against your own requirements.
1. **No self-serve customer Admin Portal yet.** Connection setup is developer-operated today; a customer's IT admin can't fully self-configure a connection through a hosted portal the way some competitors offer. Self-serve config is on Clerk's roadmap ([Clerk, new plans](https://clerk.com/changelog/2026-02-05-new-plans-more-value.md)).
2. **Audit is an event feed, not a tamper-resistant audit-log product.** Clerk's [Application Logs](https://clerk.com/docs/guides/dashboard/logs/application-logs.md) launched May 6 2026 as a dashboard event feed with filters and JSON export of entries, with retention by plan (1 day on Hobby, 7 days on Pro, 30 days on Business, custom on Enterprise) ([Clerk, Application Logs](https://clerk.com/changelog/2026-05-06-application-logs.md)). Pair it with [webhooks](https://clerk.com/docs/guides/development/webhooks/overview.md) for real-time event delivery. It is not marketed as an immutable or tamper-resistant audit-log product, and Clerk does not document native SIEM streaming or bulk log export as of June 2026. If your buyers require a dedicated, immutable audit-log product with SIEM streaming, evaluate that gap directly.
3. **SOC 2 sits on Business; HIPAA needs Enterprise.** Clerk's SOC 2 report becomes available on the Business plan, and HIPAA support with a signed BAA sits on the Enterprise (custom) tier, not the entry tiers ([Clerk Pricing](https://clerk.com/pricing)). If your buyers require a BAA, budget for Enterprise.
4. **SMS is billed.** Clerk passes SMS through at about $0.01 per message for US and Canada (market rate internationally) with no separate MFA license fee ([Clerk Pricing](https://clerk.com/pricing)). It's a metered pass-through of the carrier cost, not free.
5. **At very high connection counts, WorkOS volume pricing is cheaper.** Clerk's per-connection rate drops with volume, but WorkOS's bottom tiers go lower at large counts ([Clerk Pricing](https://clerk.com/pricing); [WorkOS Pricing](https://workos.com/pricing)). If you're standing up hundreds of connections, model both.
6. **EASIE is multi-tenant.** As the note above states, use SAML when strict single-tenant isolation is required.
7. **Reliability: like every provider, Clerk has had incidents.** Clerk publishes candid postmortems for its major outages, which is a credibility signal rather than a red flag, and other providers' incidents get the same evenhanded treatment in the risk section. Don't read transparency as instability; read the absence of postmortems as the thing to question.
## Implementation and operational considerations
Buying beats building for almost every team that isn't an identity vendor. A basic in-house SSO build runs roughly 12 to 16 weeks and on the order of $100k to $120k ([ScaleKit](https://www.scalekit.com/blog/build-vs-buy-how-to-approach-sso-for-your-saas-app)), and that's before the maintenance tail. Integrating a managed provider takes hours to days. The gap isn't just the initial code; it's the certificate rotations, IdP onboarding, and metadata upkeep that never stop.
Three-year totals depend heavily on whose model you read, so attribute every figure to its source. WorkOS's own three-year model puts a homegrown build at roughly $3.56M against a managed cost near $577k, using its own labor-rate and growth assumptions ([WorkOS, build vs buy ROI](https://workos.com/blog/build-vs-buy-part-ii-roi-comparison-between-homegrown-and-pre-built-solutions)). That model comes from a vendor selling the managed alternative, so read it as a directional argument rather than a neutral benchmark, and plug in your own team's rate and scope before trusting any total.
| Dimension | Build in-house | Buy a managed provider |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
| Time to first SSO customer | 12 to 16 weeks ([ScaleKit](https://www.scalekit.com/blog/build-vs-buy-how-to-approach-sso-for-your-saas-app)) | Hours to days |
| Up-front cost | \~$100k to $120k for a basic build ([ScaleKit](https://www.scalekit.com/blog/build-vs-buy-how-to-approach-sso-for-your-saas-app)) | Subscription; no build |
| 3-year total (WorkOS's own model) | \~$3.56M build vs \~$577k managed ([WorkOS](https://workos.com/blog/build-vs-buy-part-ii-roi-comparison-between-homegrown-and-pre-built-solutions)) | Subscription over the same period |
| Cert rotation | Your team owns every rollover | Handled by the provider |
| Metadata maintenance | Per-connection, ongoing | Handled by the provider |
| New protocol support (e.g. OIDC after SAML) | Another build cycle | Already shipped |
| SCIM provisioning | Build and maintain a SCIM server | Included or add-on, maintained for you |
The ongoing burden is what most build estimates miss. These costs recur for the life of every connection, whether you built the system or bought it (a managed provider just absorbs most of them):
- **Certificate rotation.** SAML signing certs expire on a 1-to-3-year cycle and need a coordinated SP-IdP rollover: stage the new cert, sync metadata both sides, cut over in an overlap window. Entra doesn't auto-propagate a renewal to connected SPs, so a missed expiry is one of the most common SSO outages ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on); [ScaleKit](https://www.scalekit.com/blog/saml-certificates-the-hidden-reason-enterprise-sso-breaks)). OIDC avoids the ritual: keys publish at a JWKS endpoint and rotate at the protocol level, so clients fetch current keys automatically ([OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)).
- **IdP onboarding.** Each new enterprise customer's connection takes coordinated setup and testing against their specific IdP, and that's per customer, every time.
- **Metadata maintenance.** SAML endpoints, certificates, and entity IDs drift as customers reconfigure their IdPs, and someone has to keep both sides in sync.
- **Support load.** SSO failures are high-severity by nature (a broken connection locks out an entire customer), so they pull senior engineers into incident response on the customer's timeline, not yours.
A managed provider removes the cert-rotation and metadata burden outright and absorbs most of the onboarding and support load, which is the practical reason "buy" wins for non-identity teams. Clerk handles this layer for you, and its session model means verification happens locally rather than round-tripping to a server on every request ([Clerk, How Clerk works](https://clerk.com/docs/guides/how-clerk-works/overview.md)). The engineering you'd spend on rollover windows and metadata drift goes back into your product.
## The enterprise SSO provider landscape in 2026
Every serious enterprise SSO provider supports both SAML and OIDC in 2026, so the protocol checkbox is no longer a differentiator. What actually separates providers is the pricing model (per-connection, per-user, per-MAU, or flat), provisioning depth (SCIM vs JIT-only), the admin and onboarding workflow you hand to customers, audit and event visibility, and the vendor's ownership and category. Those are the axes that move a buying decision now.
### How the providers cluster
Three categories cover most of the market, and the category usually predicts the pricing model and the operational burden.
**DIY and self-host.** Keycloak, Authentik, SimpleSAMLphp, and Shibboleth ship under free open-source licenses, and they cover SAML, OIDC, and (for Keycloak and Authentik) SCIM ([Keycloak](https://www.keycloak.org/); [authentik](https://goauthentik.io/features/)). The license is free; running the identity service is not. You patch it, scale it, monitor it, and own every CVE on your own clock. Authentik's own SAML assertion-injection advisory (CVE-2026-25922, configuration-dependent) is a reminder that self-hosting moves the remediation deadline onto your team ([authentik advisory](https://github.com/goauthentik/authentik/security/advisories/GHSA-jh35-c4cc-wjm4)).
Legacy and enterprise IdPs are the second cluster: Okta Workforce, Ping, Microsoft Entra, and OneLogin. These are built for managing a workforce across hundreds of internal apps, priced per user, and strongest when the buyer is IT rather than a product team.
Modern developer auth platforms are the third: Clerk, WorkOS, Auth0, PropelAuth, Frontegg, Descope, Kinde, Stytch, and ScaleKit. These target the engineer adding SSO to a B2B SaaS product, and they mostly price per connection or per MAU rather than per seat.
Ownership matters here because several "independent" names now sit inside larger companies. Okta completed its acquisition of Auth0 in 2021 and runs it as a separate CIAM business unit ([Auth0, 2021](https://auth0.com/blog/okta-acquisition-announcement/)); the all-stock deal was valued at roughly $6.5B ([Auth0, 2021](https://auth0.com/blog/okta-auth0-announcement/)). Thoma Bravo owns Ping, which absorbed ForgeRock after a 2022 take-private ([Ping / Thoma Bravo](https://press.pingidentity.com/2022-10-18-Thoma-Bravo-Completes-Acquisition-of-Ping-Identity)). Twilio acquired Stytch in November 2025 ([Stytch](https://changelog.stytch.com/announcements/2025-11-14-a-new-chapter-begins-stytch-joins-twilio)). One Identity owns OneLogin ([Forrester](https://www.forrester.com/blogs/perspectives-on-one-identitys-acquisition-of-onelogin/)).
### A decision-aid comparison
This table is a decision aid, not a directory. It covers the providers a B2B SaaS team is most likely to shortlist, on the dimensions that actually differ. Pricing and audit cells were re-verified in June 2026; treat them as starting points and confirm current terms on each vendor's page.
| Provider | Category | SAML | OIDC | SCIM | Pricing model | Admin Portal | Audit/event logs | Best for |
| -------------------------- | :----------: | :--: | :--: | :---------: | --------------------------------------------------------- | :----------: | -------------------------------------------- | ---------------------------------------------------- |
| Clerk | Dev platform | Yes | Yes | Yes | Per-connection (1 included, then $75/$60/$30/$15 by tier) | Roadmap | Application Logs (event feed) + webhooks | React/Next.js B2B SaaS adding SSO fast |
| WorkOS | Dev platform | Yes | Yes | Yes | Per-connection ($125 down to $50) | Yes | Dedicated audit-log product + SIEM streaming | Enterprise-first apps at high connection counts |
| Auth0 | Dev platform | Yes | Yes | Yes | Per-MAU + 30-connection cap | Yes | Tenant log streams + log events | Large integration catalog, MAU-based teams |
| Okta (Workforce) | Legacy IdP | Yes | Yes | Yes | Per-user ($6 to $17 + $1,500 min) | Yes | System Log + Log Streaming to SIEM | Workforce IAM across many internal apps |
| Microsoft Entra | Legacy IdP | Yes | Yes | Yes | Per-user (P1 $6 / P2 $9) | Yes | Sign-in and audit logs + Monitor export | Microsoft 365 shops, hybrid environments |
| Ping | Legacy IdP | Yes | Yes | Yes | Per-user ($3, 5k-user min) | Yes | PingOne audit and activity logs | Regulated, hybrid, very large workforces |
| PropelAuth | Dev platform | Yes | Yes | Higher tier | Flat $150/mo, unlimited connections | Yes | Activity log + webhooks | Many SSO connections at a flat price |
| Frontegg | Dev platform | Yes | Yes | Yes | PAYG free tier, then custom | Yes | Audit logs (embeddable) | Embedded admin UI for end customers |
| Keycloak / Authentik (DIY) | Self-host | Yes | Yes | Yes | Self-host (free license, infra cost) | No | Self-managed event logs | Full control, no per-connection fees, you operate it |
A few notes on the cells. Clerk's SCIM (Directory Sync) reached GA in April 2026 and is included with an enterprise connection at no extra charge ([Clerk Changelog](https://clerk.com/changelog/2026-04-16-directory-sync.md)); its connection pricing comes from the [Clerk pricing page](https://clerk.com/pricing). WorkOS connection pricing runs $125 down to $50 per connection by volume ([WorkOS Pricing](https://workos.com/pricing)). Auth0 prices on MAU with a 30-connection cap that becomes a cost cliff for many-tenant apps ([Auth0 Pricing](https://auth0.com/pricing)). Okta is per-user with a $1,500 annual minimum ([Okta Pricing](https://www.okta.com/pricing/)), Entra is per-user at P1 $6 / P2 $9 ([Entra Pricing](https://www.microsoft.com/en-us/security/business/microsoft-entra-pricing)), and Ping is $3 per user with a 5,000-user minimum ([Ping Pricing](https://www.pingidentity.com/en/platform/pricing.html)). PropelAuth charges a flat $150/mo for unlimited SSO connections, with SCIM on its higher tier ([PropelAuth Pricing](https://www.propelauth.com/pricing)). Frontegg starts on a pay-as-you-go free tier and moves to custom enterprise pricing ([Frontegg Pricing](https://frontegg.com/pricing)).
On the Admin Portal column: WorkOS, PropelAuth, and Frontegg ship a customer-facing self-serve portal where your customer's IT admin configures their own connection. Clerk does not have a self-serve customer Admin Portal yet; connections are developer-operated today, with self-serve configuration on the roadmap ([ScaleKit](https://www.scalekit.com/blog/is-clerk-the-right-fit-for-b2b-ai-apps)). On the audit column, the wording is deliberately neutral and capability-based. WorkOS sells a dedicated audit-log product with SIEM streaming, and its own [audit-logs page](https://workos.com/audit-logs) does not use the words "tamper-resistant" or "immutable," so this guide doesn't either. Clerk's [Application Logs](https://clerk.com/changelog/2026-05-06-application-logs.md) are a dashboard event feed plus webhooks, not a dedicated audit-log product.
### The niche and long-tail vendors
A handful of smaller platforms are worth a line where they change a pricing or ownership calculation. ScaleKit gives you 1 free connection and then $60 per connection, undercutting WorkOS at low-to-mid volume. PropelAuth ($150/mo) and Kinde ($75/mo) sell flat, unlimited-connection plans, which beats per-connection math once you pass a few enterprise customers. Stytch is now Twilio-owned and leans into agent identity, while Descope sits at the pricier end (Growth from $799/mo). SimpleSAMLphp and Shibboleth are SAML-focused open-source projects (Shibboleth is the backbone of the academic InCommon and eduGAIN federations), and OneLogin is the One Identity-owned mid-market option ([ScaleKit pricing](https://www.scalekit.com/auth-for-saas); [Kinde pricing](https://kinde.com/pricing/); [Descope pricing](https://www.descope.com/pricing)).
### What the analysts say (and don't)
Gartner's Magic Quadrant for Access Management, published November 11, 2025, named Okta, Microsoft, and Ping among its Leaders (Ping's 9th consecutive year), alongside Transmit Security ([Okta press release](https://www.okta.com/newsroom/press-releases/okta-named-a-leader-in-2025-gartner-magic-quadrant/); [Ping press release](https://www.prnewswire.com/news-releases/ping-identity-recognized-as-a-leader-in-2025-gartner-magic-quadrant-for-access-management-302618835.html)). The Forrester Wave for Workforce Identity Security Platforms, Q2 2026, named Microsoft and Okta as Leaders ([Forrester](https://www.forrester.com/blogs/announcing-the-forrester-wave-workforce-identity-platforms-q2-2026/)).
Read those reports for what they are. They rank workforce and enterprise IAM, and they don't evaluate the newer developer-first B2B platforms like Clerk and WorkOS on the same scale. For a product team adding SSO, analyst placement is one input, not the whole picture. On market size, the global SSO market is roughly $4.40B in 2026 by [Fortune Business Insights](https://www.fortunebusinessinsights.com/single-sign-on-market-111254), while [Mordor Intelligence](https://www.mordorintelligence.com/industry-reports/single-sign-on-market) puts 2025 nearer $3.34B. Analyst figures spread, so treat any single number as directional.
### Where Clerk fits, and where it doesn't
Clerk is the best fit for a React or Next.js B2B SaaS that wants SAML, OIDC, and SCIM working quickly, at low-to-moderate connection counts, without paying an SSO tax to ship the feature. The first enterprise connection is included, SCIM rides along at no extra charge, and the developer experience is the selling point.
Clerk is not the best fit in four specific cases. If you need a mature self-serve customer Admin Portal today, WorkOS, PropelAuth, or Frontegg already ship one. If you need a dedicated, separately-sold audit-log product with SIEM streaming, WorkOS is purpose-built for it. If you operate at very high connection volume, WorkOS's per-connection rate floor (down to $50) wins on unit economics. And if machine or agent identity has to be first-class on day one, that's not Clerk's current strength ([ScaleKit](https://www.scalekit.com/blog/is-clerk-the-right-fit-for-b2b-ai-apps)). Pick the tool that matches the constraint.
### Reliability and incident transparency as a buyer signal
Every provider in that table has had incidents. Since they all go down eventually, the useful buyer signal is whether a vendor publishes a candid postmortem when it happens. Clerk and WorkOS publish detailed blog postmortems ([Clerk](https://clerk.com/blog/2026-02-10-dns-outage-postmortem.md); [WorkOS](https://workos.com/blog/service-disruption-on-october-20-2025)). Microsoft and Auth0 publish formal PIRs and RCAs through their status channels ([Auth0 status](https://status.auth0.com)). Ping, PropelAuth, and Frontegg are status-page-only, which is a gap in public evidence rather than a verdict on their uptime. The earlier risk section weights this disclosure quality alongside protocol breadth as a continuity hedge; the short version for buyers is that a willingness to write the postmortem is itself a maturity signal.
## Future-proofing your SSO choice (2026 and beyond)
The protocol you pick today has to survive the next decade of identity, not just this quarter. The short version: SAML stays, OIDC keeps winning new builds, and a third layer (workloads and AI agents) is growing fast on top of OAuth. The questions below answer where each trend actually pushes the decision.
### Is SAML dead?
No. SAML is entrenched, not declining. It anchors massive federations that aren't going anywhere: InCommon connects 1,000+ research, education, and industry partners and 6,000+ services ([InCommon](https://incommon.org/federation)), and eduGAIN spans 80+ national federations, 10,000+ providers, and roughly 27M users ([eduGAIN status](https://technical.edugain.org/status)). FedRAMP, Login.gov, and academic federation all keep it in place.
The honest read is a plateau, not a death spiral. SAML stops winning new greenfield projects but holds its installed base for the next decade ([Duende, Apr 2026](https://duendesoftware.com/blog/20260416-the-history-and-future-of-saml)). If your buyers run government, finance, or higher-ed IdPs, you'll be speaking SAML well into the 2030s.
### Is OIDC replacing SAML?
Partly. OIDC is the default for new builds, while SAML is retained for the enterprise and government installed base. The two coexist, and the IdPs in the middle increasingly act as "protocol translators" that broker between them so the wire format becomes an implementation detail ([Duende, May 2026](https://duendesoftware.com/blog/20260528-saml-and-openid-connect)).
One development narrows OIDC's last real gap. OpenID Federation 1.0 was finalized in February 2026, extending OIDC into the multilateral, many-to-many trust that used to be a SAML-only strength ([OpenID Foundation](https://openid.net/openid-federation-1-0-final-specification-approved/)). eduGAIN is already piloting it alongside SAML. The direction is OIDC-first, but "replace" overstates the pace.
### How does zero trust change the SSO decision?
Barely, at the protocol level. Zero trust is protocol-neutral: NIST SP 800-207 requires authenticating both the subject and the device before each session, and says nothing about SAML versus OIDC ([NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final)). Either protocol can feed a zero-trust architecture.
Watch the gap between adoption and maturity. Gartner found 63% of organizations had fully or partially implemented a zero-trust strategy as of April 2024 ([Gartner](https://www.gartner.com/en/newsroom/press-releases/2024-04-22-gartner-survey-reveals-63-percent-of-organizations-worldwide-have-implemented-a-zero-trust-strategy)), but predicted only 10% would run a mature, measurable program by 2026 ([Gartner](https://www.gartner.com/en/newsroom/press-releases/2023-01-23-gartner-predicts-10-percent-of-large-enterprises-will-have-a-mature-and-measurable-zero-trust-program-in-place-by-2026)). Where it does bite is session design. Continuous, per-request verification favors short-lived JWTs over long-lived sessions, which is one practical edge for OIDC. Clerk's session model fits this directly with its \~60-second session JWTs ([How Clerk works](https://clerk.com/docs/guides/how-clerk-works/overview.md)).
### What do passwordless and passkeys mean for SSO?
They're complementary, not competing. Passkeys authenticate the user at the IdP; SSO then federates that identity to your application. A passkey is how someone proves they're Jane at her company's identity provider, and SAML or OIDC carries that proof to you.
The enterprise numbers are strong. A FIDO Alliance survey (Sapio, n=400) found 87% of US and UK workforces deploying passkeys for employee sign-ins, a 77% reduction in help-desk calls, and 90% reporting a positive security impact ([FIDO Alliance](https://fidoalliance.org/new-fido-alliance-research-shows-87-percent-us-uk-workforces-are-deploying-passkeys-for-employee-sign-ins/)). The FIDO Passkey Index from October 2025 measured 93% versus 63% sign-in success rates, 8.5 seconds versus 31.2 seconds to authenticate, and an 81% drop in sign-in help-desk calls ([FIDO Passkey Index](https://fidoalliance.org/fido-alliance-launches-passkey-index-revealing-significant-passkey-uptake-and-business-benefits/)).
Two signals make this the default path. NIST SP 800-63-4 recognizes synced passkeys at AAL2, removing the main compliance blocker for enterprise FIDO2 ([NIST](https://pages.nist.gov/800-63-4/sp800-63c/fal/)), and Microsoft moved synced passkeys and passkey profiles to general availability in Entra ID in 2026, migrating existing FIDO2 passkey configurations into a default profile ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/fundamentals/whats-new)). Passkey support belongs on your checklist regardless of which federation protocol you ship.
### How do AI agents and machine identities authenticate?
On a different layer entirely. Reusing the three-layer model from the primer, agents and machine-to-machine traffic live on the workload layer, which runs on the OAuth 2.0 family: the `client_credentials` grant, RFC 8693 token exchange for delegation chains ([RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693)), OIDC-style JWT assertions, and workload identity via SPIFFE/SPIRE and the IETF WIMSE working group ([WIMSE](https://datatracker.ietf.org/wg/wimse/about/)). The interactive SAML and OIDC login flows are built for a human at a browser, so they don't apply to a non-human caller. SAML has no role in agent or M2M flows; OAuth and the OIDC-style JWTs layered on it do, which is a modest OIDC-leaning signal if your product touches agents.
The standards are landing quickly. MCP authorization is built on OAuth 2.1 plus RFC 9728 ([MCP auth spec](https://modelcontextprotocol.io/specification/draft/basic/authorization)); the A2A protocol passed 150+ organizations in its first year ([Linux Foundation](https://www.prnewswire.com/news-releases/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year-302737641.html)); OWASP published an Agentic Top 10 that ranks identity and privilege abuse (ASI03) among the top risks ([OWASP](https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/)); the OpenID Foundation published agent-identity work ([arXiv 2510.25819](https://arxiv.org/abs/2510.25819)); and NIST launched an AI Agent Standards Initiative in February 2026 ([NIST](https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure)).
The risk pressure is real. Credential abuse was the initial vector in 22% of 2025 breaches ([Verizon DBIR 2025](https://www.verizon.com/about/news/2025-data-breach-investigations-report)), and machine identities already outnumber humans by roughly 82 to 1 ([CyberArk, 2025](https://www.cyberark.com/press/machine-identities-outnumber-humans-by-more-than-80-to-1-new-report-exposes-the-exponential-threats-of-fragmented-identity-security/)). Clerk supports machine-to-machine tokens for this layer, but agent identity isn't a first-class product area for Clerk yet, so size that gap against your roadmap rather than assuming it's covered.
### Which regulations will shape SSO by 2026?
Three, and they all push toward stronger identity controls. The EU AI Act reaches full application on August 2, 2026, with penalties up to 7% of global turnover for prohibited practices under Article 5 and up to 3% for most other operator obligations ([EU AI Act Art. 99](https://artificialintelligenceact.eu/article/99/)). DORA applies from January 17, 2025 for the EU financial sector ([EUR-Lex, Reg. (EU) 2022/2554, Art. 64](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)). NIS2 Article 21(2)(j) explicitly names multi-factor authentication as a cybersecurity risk-management measure ([EUR-Lex, Dir. (EU) 2022/2555, Art. 21](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng)), and Germany's NIS2 implementation took effect December 6, 2025, giving in-scope entities three months to register with the BSI, by March 6, 2026 ([§33 BSIG](https://www.gesetze-im-internet.de/bsig_2025/__33.html); [BSI](https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/NIS-2-FAQ/NIS-2-FAQ-allgemein/FAQ-zu-NIS-2.html)).
None of these name a protocol. What they demand is identity-attributable audit trails and phishing-resistant authentication, which favors providers with strong provisioning, durable audit evidence, and passkey support no matter whether the federation runs on SAML or OIDC.
| Trend | Implication for protocol choice |
| ------------------------------------- | ---------------------------------------------------------------------------------- |
| SAML entrenchment plateaus | Keep SAML for the government, finance, and higher-ed installed base |
| OIDC-first plus OpenID Federation 1.0 | Default new builds to OIDC; its last multilateral-trust gap is closing |
| Zero trust and short-lived sessions | Slight edge to OIDC's short-lived JWTs for per-request verification |
| Passkeys at the IdP | Protocol-neutral; require passkey support either way |
| AI agents and machine identities | OAuth family, not SAML; an OIDC-leaning signal for agent-touching products |
| EU AI Act, DORA, NIS2 | Protocol-neutral; weight provisioning, audit evidence, and phishing-resistant auth |
The throughline: pick a provider that speaks both protocols and treats passkeys, SCIM, and audit as first-class. That keeps the federation protocol an implementation detail you can change later, instead of a bet you're locked into.
## Common myths and misconceptions about SAML and OIDC
Most of the confusion around SAML and OIDC comes from treating slogans as facts. Here are the nine claims that come up most, with what the evidence actually shows.
| Myth | Reality |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "SAML is dead." | SAML is entrenched across enterprise, government, and higher education. The honest forecast is a plateau over the next decade, not a decline ([Duende, 2026](https://duendesoftware.com/blog/20260416-the-history-and-future-of-saml)). |
| "OIDC is always more secure than SAML." | Both protocols have shipped critical CVEs. Implementation quality and provider hygiene dominate real-world outcomes, and NIST SP 800-63C-4 recognizes both formats at every federation assurance level ([NIST SP 800-63C-4](https://csrc.nist.gov/pubs/sp/800/63/c/4/final)). |
| "SAML is enterprise-only and OIDC is consumer-only." | OIDC is widely used inside the enterprise. The line keeps blurring as identity providers learn to speak both protocols. |
| "You must pick one protocol." | Production B2B usually supports both behind a single integration, so the protocol becomes an implementation detail. |
| "SAML works fine for SPAs and mobile apps." | SAML is a poor fit for both, and the only paths are workarounds: broker to OIDC, or use allowlisted native redirects. OIDC with PKCE is the native default ([RFC 8252](https://datatracker.ietf.org/doc/html/rfc8252)). |
| "JWTs can't be revoked, so OIDC is insecure." | Short-lived tokens plus rotation and introspection bound the exposure window. Revocation is a design choice you make in the implementation, so the protocol itself sets no hard limit. |
| "IdP-initiated SSO is as safe as SP-initiated." | IdP-initiated flows drop the `InResponseTo` binding, which widens assertion-injection and replay exposure ([Scott Brady](https://www.scottbrady.io/saml/dangers-of-idp-initiated-sso)). |
| "SCIM is just an SSO add-on." | SSO handles authentication. SCIM handles lifecycle provisioning and deprovisioning, a separate layer that runs whether or not anyone signs in ([WorkOS, SCIM vs JIT](https://workos.com/blog/scim-vs-jit-what-s-the-difference)). |
| "AI agents log in with SAML or OIDC like users." | Agents use the OAuth workload layer (client-credentials, token exchange). Interactive login flows don't apply, and SAML has no role there. |
The pattern across all nine: the protocol you choose matters less than how carefully you implement it and how disciplined your provider is about disclosure.
## Measuring success: metrics for your SSO implementation
Measure your SSO rollout against four things, in priority order: authentication speed, user satisfaction, security incident reduction, and developer productivity. Rank them in that order, because a fast, trusted, breach-resistant flow is the point. Shipping it quickly is not.
| Metric | How to measure | Benchmark / signal | Source |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Authentication speed | Median time-to-authenticate and sign-in success rate. Token size is a secondary efficiency signal (SAML assertions run 2-8 KB; OIDC ID tokens run 0.9-1.5 KB). | Passkeys hit 8.5s vs 31.2s and a 93% vs 63% success rate. Anything over 20s reads as slow. | [FIDO Passkey Index](https://fidoalliance.org/fido-alliance-launches-passkey-index-revealing-significant-passkey-uptake-and-business-benefits/), [Corbado](https://www.corbado.com/kpi/time-to-authenticate) |
| User satisfaction | Help-desk authentication tickets and login-abandonment rate. | Passkeys show 77% and 81% help-desk reductions and 82% positive UX impact. | [FIDO enterprise](https://fidoalliance.org/new-fido-alliance-research-shows-87-percent-us-uk-workforces-are-deploying-passkeys-for-employee-sign-ins/), [FIDO Passkey Index](https://fidoalliance.org/fido-alliance-launches-passkey-index-revealing-significant-passkey-uptake-and-business-benefits/) |
| Security incident reduction | Mean-time-to-deprovision (SCIM) and credential-abuse exposure. | Credential abuse was the initial vector in 22% of 2025 breaches; the human element factored into 68% of 2024 breaches. | [Verizon DBIR 2025](https://www.verizon.com/about/news/2025-data-breach-investigations-report), [DBIR 2024](https://www.verizon.com/business/resources/reports/2024-dbir-data-breach-investigations-report.pdf) |
| Developer productivity | Time-to-first-SSO-customer. | Days with a managed provider, versus 12 to 16 weeks to build SSO in-house. | [ScaleKit](https://www.scalekit.com/blog/build-vs-buy-how-to-approach-sso-for-your-saas-app) |
Track each over time, not as a one-time launch number. A median that creeps past 20 seconds or a help-desk queue that fills with login tickets tells you the rollout is regressing, regardless of how clean the integration looked on day one.
> Developer productivity ranks last on purpose. When a faster shipping path conflicts with authentication speed, user satisfaction, or security incident reduction, those three win every time. Time-to-first-SSO-customer is a real input, and it sits below the metrics that affect the people signing in and the data you're protecting.
## Recommendation: choosing OIDC vs SAML for enterprise SSO in 2026
Go OIDC-first for every new build and for all SPA, mobile, API, and AI-agent surfaces, where it's the cleaner and often the only sane fit. Keep and operate SAML for the enterprise and government installed base that still runs it, and don't force-migrate connections that work. The way to stop betting on a protocol is to support both behind one integration, add SCIM for lifecycle provisioning, and treat "SAML or OIDC" as an implementation detail the provider absorbs. Pick that provider on total cost of ownership, platform fit, SCIM depth, and an honest security posture, not on a protocol security ranking, because NIST recognizes both at every assurance level. For a React or Next.js B2B SaaS at low-to-moderate connection counts that wants SAML, OIDC, and SCIM fast without an SSO tax, Clerk is a strong fit, with named caveats: there's no self-serve customer Admin Portal yet, audit is an event feed plus webhooks rather than an immutable audit-log product, and WorkOS wins on price at very high connection volume.
If you remember nothing else:
1. New builds and SPA, mobile, API, or agent surfaces go OIDC-first; OIDC + PKCE is the default for native and single-page apps.
2. The enterprise and government installed base still runs SAML, so keep it and dual-run via a broker rather than force-migrating working connections.
3. Support both protocols behind one enterprise-connection model and add SCIM, since SSO authenticates while SCIM manages the account lifecycle your SOC 2 offboarding depends on.
4. Choose the provider on TCO, platform fit, SCIM, and a candid security posture, not on a SAML-vs-OIDC security ranking; NIST recognizes both at every assurance level.
5. Clerk fits a React or Next.js B2B SaaS at low-to-moderate connection counts; weigh the no-self-serve-Admin-Portal and event-feed-audit caveats, and model WorkOS at very high connection volume.
## Frequently asked questions
## FAQ
### What is the difference between SAML and OIDC?
Both authenticate a user against their organization's identity provider, then hand your app a signed proof of identity. SAML 2.0 moves verbose, signed XML assertions through the browser and is entrenched in enterprise, government, and higher education. OIDC layers compact, signed JSON tokens on top of OAuth 2.0 with a self-describing discovery endpoint, which fits modern web, mobile, and API surfaces. OIDC is the default for new builds.
### What is the difference between OAuth, OpenID Connect, and SAML?
OAuth 2.0 is authorization: it grants a client delegated access to a resource and says nothing reliable about who the user is. OIDC is authentication built on OAuth 2.0; it keeps OAuth's flows and adds an ID token that answers who signed in. SAML is authentication plus federation expressed in XML, independent of OAuth. OAuth isn't a login protocol on its own; OIDC and SAML are.
### Which is more secure, SAML or OIDC?
Neither is inherently safer. Both have had critical CVEs, from SAML signature-wrapping and XML canonicalization flaws to OAuth and OIDC redirect and token-handling bugs, and implementation and provider quality dominate the outcome far more than the protocol choice. NIST SP 800-63C-4 recognizes both SAML and OIDC at every federation assurance level ([NIST, 2025](https://csrc.nist.gov/pubs/sp/800/63/c/4/final)). Pick a provider with a transparent security posture over a protocol you think is safer.
### Is SAML dead?
No. SAML 2.0 has been an OASIS standard since 2005 and remains deeply entrenched across enterprise, government, and higher education, where it anchors a large installed base of working federation. It's plateauing rather than declining: few new greenfield projects choose it, but the connections already in production aren't going anywhere. Plan to keep operating SAML for years, not to retire it on a timeline.
### Is OIDC replacing SAML?
OIDC is the default for new builds and is the only practical fit for single-page apps, mobile, and API surfaces, so new federation increasingly starts there. It is not erasing SAML. Enterprise and government buyers keep large SAML estates in production, and major identity providers now act as protocol translators between the two. Expect a long hybrid, not a clean cutover.
### Should I migrate from SAML to OIDC?
Usually no, not as a forced cutover. The pragmatic path is to dual-run: keep working SAML connections in place and add OIDC for new ones, brokering both through an identity layer so the protocol becomes an implementation detail. A typical estate settles into a stable hybrid rather than a clean migration. Don't break a connection a customer's security team already approved just to standardize on one protocol.
### Can one provider support both SAML and OIDC for enterprise SSO?
Yes, and that's the pragmatic enterprise answer. A provider that handles both behind one enterprise-connection model lets you onboard a SAML-only customer and an OIDC-only customer the same way, then add SCIM provisioning, without betting on a single protocol. Clerk, WorkOS, Auth0, PropelAuth, and Frontegg all do this. They differ on pricing model, provisioning depth, admin workflow, and audit visibility, which is where the real evaluation happens.
### Can I use SAML for mobile or single-page apps?
It's a poor fit, workaround-only rather than impossible. SAML assumes browser redirects and signed XML, and there's no standards-body native SAML SDK, so making it work in native or SPA contexts means brokering or allowlisted redirects. OIDC with Authorization Code + PKCE is the default for both ([RFC 8252](https://datatracker.ietf.org/doc/html/rfc8252)). If one enterprise customer mandates a SAML-only IdP, broker SAML to OIDC at the provider instead of putting XML in the browser.
### What is SCIM and do I need it instead of JIT?
SCIM is a provisioning protocol that creates, updates, and deactivates user accounts independent of any login. Just-in-time (JIT) provisioning creates an account on first SSO sign-in but can't deactivate one, so it fails offboarding controls. For SOC 2 Type II you effectively need SCIM, because deprovisioning a departed employee is the control auditors check ([WorkOS, SCIM vs JIT](https://workos.com/blog/scim-vs-jit-what-s-the-difference)). JIT is fine before you go upmarket; SCIM is required after.
### What is the SSO tax?
It's the practice of gating enterprise SSO behind a vendor's most expensive tier, charging a steep premium for a feature that costs little to ship. The community tracks the markups on [sso.tax](https://sso.tax/), and they can reach thousands of percent over the next tier down. SAML gets gated more often because requesting it signals an enterprise buyer with a budget. When you ship SSO in your own product, avoid putting that tax on your customers.
### How do I choose between SAML and OIDC?
Decide by application surface, your customers' IdP estate, your compliance obligations, and total cost of ownership, in that order. New builds and SPA, mobile, or API surfaces point to OIDC; a SAML-only enterprise IdP forces SAML. The protocol is usually downstream of the provider you pick, so most B2B teams land on supporting both and let the provider absorb the difference. NIST recognizes both at every assurance level, so this isn't a security ranking.
### What does enterprise SSO cost?
Managed providers price either per-connection (one configured customer IdP) or per-MAU (total active users). Most per-connection rates cluster in roughly the $50 to $150 range, often dropping with volume. Per-connection scales with your number of enterprise customers; per-MAU scales with seats. Watch for the SSO tax gating the feature behind a punitive tier, plus SCIM and MFA add-ons, certificate-rotation labor, and compliance evidence that a security review will demand.
### How do AI agents authenticate, do they use SAML or OIDC?
They use the OAuth 2.0 workload layer, not interactive login. Non-human callers authenticate with the client-credentials grant, RFC 8693 token exchange for delegation chains, and OIDC-style JWT assertions, plus workload identity federation. SAML has no role here. The interactive SAML and OIDC sign-in flows assume a human at a browser, but the OAuth machinery and the JWTs layered on it apply directly to agents and machine-to-machine traffic.
### Do SAML and OIDC handle user provisioning?
No. SAML and OIDC handle authentication, proving who is signing in, while SCIM handles provisioning, the create-update-deactivate lifecycle of the account itself. They're separate layers that solve separate problems. SSO can authenticate a user the moment their access is revoked at the IdP, but only SCIM deactivates the downstream account. If you need automated offboarding for compliance, you need SCIM alongside your SSO protocol, not instead of it.
### Does Clerk support SAML, OIDC, and SCIM?
Yes. Clerk supports SAML, OIDC, and EASIE enterprise connections through one model, plus SCIM via Directory Sync, which reached general availability in 2026 with immediate session revocation on deprovision. See the [enterprise SSO docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md). Honest caveats: there's no self-serve customer Admin Portal yet, so connection setup is developer-operated, and audit is a dashboard event feed plus webhooks rather than a tamper-resistant audit-log product with SIEM streaming.