OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide - Part 3

This is Part 3 of a four-part series on choosing between OIDC and SAML for enterprise SSO in 2026. Part 2 covered total cost of ownership and security risks. This part completes the risk assessment framework and provides the decision guide for choosing your protocol strategy.

Completing the risk assessment framework

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⁠). 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⁠).

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); a Postgres auto-upgrade incident in September 2025 (Clerk, 2025); a DNS outage on February 10, 2026 lasting 2h32m with under 5% of API volume impacted (Clerk, 2026); a roughly 90-minute database query-plan incident on February 19, 2026 (Clerk, 2026); and a 26-minute Cloud SQL live-migration incident on March 10, 2026 (Clerk, 2026). After the September 2025 incident Clerk isolated the Session API onto its own service with read-replica failover (Clerk Changelog, 2025).
2. WorkOS publishes postmortems too: an AuthKit outage on October 20-21, 2025 tied to an AWS us-east-1 disruption (WorkOS, 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⁠).
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⁠); 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 did not record a multi-hour global authentication outage analogous to the Azure or GCP issues above in the 2024-2026 period. Its headline event was the 2023 support-system breach, a security incident rather than an availability one, with a root-cause writeup at Okta Security⁠.
5. Auth0 publishes RCA documents on its status page (Auth0 status⁠; 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.

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."

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⁠; AppAuth⁠). 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⁠, 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⁠; SMART on FHIR⁠ 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⁠).
  • 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⁠), so the "recommended" column reflects platform fit and customer reality, not a security ranking.

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.

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, WorkOS⁠, Auth0⁠, PropelAuth⁠, and Frontegg⁠ 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, 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.

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), and a custom OIDC provider connects via its discovery endpoint (Clerk, OIDC custom provider).
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). Group-to-role and custom attribute mapping reached GA on May 21 2026 (Clerk, groups and attributes GA). It's available across plans, and per the pricing page is included with an enterprise connection at no extra charge (Clerk 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).
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).
4. Org-level B2B SSO and JIT. Enterprise SSO binds to organizations (Clerk, organization-level SSO), and JIT provisions accounts on first SSO login when you don't need full SCIM (Clerk, JIT provisioning).
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). That maps cleanly onto zero-trust's per-request verification.
6. Transparent security posture. Clerk publishes its CVEs, a formal vulnerability disclosure policy, 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.

Honest caveats

Every strength above has a limit. Name these before you commit, and weigh them against your own requirements.

1. Self-serve SSO is new and scoped to Organizations. As of June 26 2026, a customer's IT admin can configure and manage their own enterprise connection — domain verification, provider setup, test, and activate — from a Security tab in <OrganizationProfile />, with no Clerk Dashboard access (Clerk, Self-serve SSO; Self-serve SSO docs). Two limits to weigh: it requires Clerk Organizations and is turned on per-organization, and the self-serve provider menu currently covers Okta, Google Workspace, Microsoft Entra ID, and custom SAML, so a custom OIDC connection still goes through developer-operated Dashboard setup.
2. Audit is an event feed, and SIEM streaming is Enterprise-tier only. Clerk's Application Logs 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). Pair it with webhooks for real-time event delivery. The Enterprise plan adds log sink destinations that stream logs to your SIEM (Clerk Pricing), but that is the only tier with streaming — on Hobby, Pro, and Business you have the dashboard feed and webhooks, not a managed export pipeline. It is also not marketed as an immutable or tamper-resistant audit-log product. If your buyers require SIEM streaming below the Enterprise tier, or a dedicated tamper-resistant audit-log product, 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). 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). 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; WorkOS 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.

In Part 4, we conclude the series by covering implementation considerations, the 2026 enterprise SSO provider landscape, future-proofing, and final recommendations.

FAQ

Should my application support both SAML and OIDC? Yes, supporting both is often the most pragmatic choice. It ensures compatibility with modern IdPs via OIDC and legacy or strict enterprise IdPs via SAML.

How does zero trust affect my SSO choice? Zero trust architecture emphasizes continuous verification and context-aware access decisions. This focus on per-request evaluation rather than perimeter trust means your session management must support frequent verification, but it does not inherently favor OIDC or SAML at the federation layer.

Do compliance frameworks prefer SAML over OIDC? Neither protocol is inherently preferred by frameworks like SOC 2 or FedRAMP, as long as it is implemented securely and meets the required assurance levels (e.g., NIST SP 800-63C).

In this series

1. OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide
2. OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide - Part 2
3. OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide - Part 3 (you are here)
4. OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide - Part 4