# OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide - Part 3 > Part 3 of 4. Start with [OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide](https://clerk.com/articles/oidc-vs-saml-for-enterprise-sso-a-2026-decision-guide.md). 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](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 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](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. **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 ``, with no Clerk Dashboard access ([Clerk, Self-serve SSO](https://clerk.com/changelog/2026-06-26-self-serve-sso.md); [Self-serve SSO docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/self-serve-sso.md)). 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](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. The Enterprise plan adds log sink destinations that stream logs to your SIEM ([Clerk Pricing](https://clerk.com/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](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. 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](https://clerk.com/articles/oidc-vs-saml-for-enterprise-sso-a-2026-decision-guide.md) 2. [OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide - Part 2](https://clerk.com/articles/oidc-vs-saml-for-enterprise-sso-a-2026-decision-guide-2.md) 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](https://clerk.com/articles/oidc-vs-saml-for-enterprise-sso-a-2026-decision-guide-4.md)