TL;DR: The right SSO protocol choice is no longer about whether OIDC is newer or SAML is older, but about deployment context, compliance evidence, continuity risk, and pricing, according to Clerk. NIST SP 800-63C-4 treats both as valid federation options, so practitioners should score the provider, the customer estate, and the operational model before choosing.
At a glance
What this is: This is a decision guide for enterprise SSO that argues protocol choice should follow application surface, customer IdP reality, compliance requirements, and provider reliability rather than protocol fashion.
Why it matters: For IAM teams, the practical question is not only federation compatibility but whether the chosen SSO model also satisfies audit evidence, offboarding, and resilience requirements across human and non-human access paths.
Context
Enterprise SSO decisions often fail when teams collapse federation, provisioning, and workload identity into one choice. Federation is the login protocol, provisioning is the lifecycle layer, and machine or agent access belongs in a different control plane entirely.
Clerk frames this part of the series as a risk assessment and decision guide for OIDC versus SAML in 2026. The central issue is not which protocol is fashionable, but which combination of protocol, provider, and operating model fits the application surface, customer identity estate, compliance burden, and continuity expectations.
Key questions
Q: What breaks when teams treat SSO as enough for identity lifecycle control?
A: Offboarding breaks first. Federation proves that a user or workload can authenticate, but it does not prove the identity has been deactivated, removed from groups, or disconnected from downstream entitlements. That is why SCIM and lifecycle governance must sit beside SSO, not inside it. Without that separation, access can persist after the trust relationship should have ended.
Q: Why do compliance reviews often care more about evidence than protocol choice?
A: Because compliance teams usually want proof of control, not a preferred federation standard. The key questions are whether the provider can show audit evidence, residency fit, and consistent operational handling of identity data. Both SAML and OIDC can satisfy assurance requirements when implemented correctly, so the surrounding documentation and governance model usually matter more than the wire format.
Q: When should organisations prioritise OIDC over SAML for single sign-on?
A: Organisations should prioritise OIDC when they are building modern web or mobile applications and want a protocol that fits OAuth 2.0 based login flows. SAML still fits many enterprise environments with established identity providers and XML based integrations. The right choice depends on the application channel, existing IdP support, and how much protocol complexity the team can sustain.
Q: What is the difference between federation and provisioning in enterprise SSO?
A: Federation is the authentication relationship that lets a user sign in through SAML or OIDC. Provisioning is the lifecycle process that creates, updates, and removes accounts and access, usually through SCIM or another lifecycle control. Teams need both if they want access to be both reachable and governable.
Technical breakdown
Federation assurance is protocol-neutral
NIST SP 800-63C-4 treats both SAML assertions and OIDC ID tokens as valid at Federation Assurance Levels 1 through 3. That means protocol selection is rarely about intrinsic assurance strength. The real differentiators are how the deployment handles audience restriction, proof of possession, assertion forgery resistance, and the surrounding operational controls. A managed provider can satisfy the same assurance level through either protocol if the implementation is correct and the trust boundaries are clear.
Practical implication: Do not use protocol brand alone as an assurance proxy; validate the surrounding controls and trust model instead.
Federation is not provisioning or workload identity
The article separates three layers that teams often blur: federation, provisioning, and workload or agent authentication. Federation covers SAML or OIDC user login. Provisioning covers SCIM and offboarding. Workload and agent access uses OAuth 2.0, token exchange, JWT assertions, and workload identity patterns such as SPIFFE, not interactive SSO flows. Conflating these layers creates design errors, especially when teams try to use human login protocols for non-human callers or rely on JIT where lifecycle deactivation is required.
Practical implication: Keep login, provisioning, and non-human access on distinct control paths so offboarding and authorization stay governable.
Provider continuity is part of the SSO decision
The guide treats availability and disclosure maturity as first-class risk inputs. A provider that publishes candid postmortems, maintains a status history, and isolates services after incidents presents a different operational profile from one that offers little public evidence. The assessment is not about punishing outages, but about whether the vendor shows enough resilience engineering and transparency to support enterprise dependence. Protocol breadth also acts as a hedge because it reduces lock-in to any single provider behaviour.
Practical implication: Include outage history, postmortem quality, and service isolation in the same decision model as protocol fit.
Threat narrative
Attacker objective: The attacker wants to turn a trusted federation artefact into unauthorized application access without needing the underlying account credentials.
- Entry occurs through a forged or stolen token or assertion when the trust boundary around federation is weak or misconfigured.
- Credential access and abuse follow when a signed assertion or token is accepted without the audience, binding, or issuer checks needed to constrain replay and misuse.
- Impact is unauthorized access to enterprise applications and downstream data, especially where the federation layer is treated as sufficient by itself.
Breaches seen in the wild
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Protocol choice is a governance outcome, not a protocol preference. The article makes clear that enterprise SSO should be chosen from the top down, beginning with application surface, customer IdP estate, compliance evidence, and pricing model. That is the correct order because federation only resolves one layer of the identity problem. Practitioner takeaway: treat SSO protocol selection as a packaging decision inside a broader identity architecture, not as the architecture itself.
Federation assurance is now a control-design question, not a SAML-versus-OIDC debate. NIST SP 800-63C-4 recognizes both protocols at the same assurance levels, which removes the false assumption that one protocol is inherently the stronger control. The real governance question is whether the deployment enforces audience restriction, proof of possession, and anti-forgery measures around whichever protocol is chosen. Practitioner takeaway: assess the control envelope, not the protocol label.
Provider transparency is a meaningful resilience signal. The article correctly weights postmortems, status history, and service isolation because SSO is now a dependency, not a convenience layer. A candid incident record does not eliminate risk, but it gives buyers evidence that operational failure modes are understood and remediated. Practitioner takeaway: include disclosure quality and service segmentation in enterprise trust decisions.
SCIM and federation solve different identity problems. The guide is right to warn that JIT alone cannot satisfy offboarding expectations because it provisions access without guaranteeing deactivation. That distinction matters for both human accounts and broader lifecycle governance. Practitioner takeaway: if a buyer expects auditability and revocation discipline, the federation decision must be paired with explicit lifecycle controls.
Enterprise SSO is converging on dual-protocol reality. Mixed IdP estates, regulatory expectations, and customer-specific constraints are pushing teams toward both SAML and OIDC rather than a forced single-standard bet. That does not mean every deployment needs both on day one, but it does mean the market is rewarding architectural flexibility over protocol ideology. Practitioner takeaway: plan for dual support unless your customer base is narrowly constrained.
From our research library:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
What this signals
Dual-protocol support is becoming the default enterprise posture. Mixed identity provider estates, regulated procurement, and lifecycle requirements are pushing teams toward SAML plus OIDC rather than a single-protocol bet. The governance question is no longer which standard wins, but whether the identity programme can absorb customer variance without creating offboarding or audit blind spots.
Lifecycle discipline will decide whether SSO choices scale. Federation can authenticate a session, but only provisioning and deprovisioning can prove that access has ended. Teams that continue to rely on login flows alone will keep discovering that access review and account removal are separate controls, not the same one.
For practitioners
- Separate federation from provisioning Map SAML and OIDC to login only, then keep SCIM and lifecycle deactivation as a distinct governance layer so offboarding does not depend on session expiry.
- Score provider continuity alongside protocol fit Use published postmortems, status history, and service segmentation as explicit evaluation criteria when comparing enterprise SSO providers.
- Align protocol choice to application surface Use OIDC for SPA, native, and API-oriented surfaces, and reserve SAML for legacy or customer-mandated enterprise IdPs.
Key takeaways
- Enterprise SSO protocol selection is really a governance decision about surface area, customer identity reality, and operational evidence.
- Both SAML and OIDC can satisfy federation assurance when the surrounding controls are implemented correctly.
- Teams that want durable enterprise access need federation, provisioning, and continuity planning to work together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63C — Federation | The article centers on federation assurance and SAML/OIDC comparison. |
| Recommendation — Use SP 800-63C to evaluate federation assurance without assuming either protocol is inherently stronger. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | SSO choice affects how access is granted and governed across enterprise systems. |
| Recommendation — Apply PR.AA-05 to ensure federated access stays tied to explicit authorization rules and lifecycle controls. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The article discusses token and assertion trust, including misuse and forgery risks. |
| Recommendation — Harden token validation paths so federated assertions cannot be replayed or accepted outside their intended context. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Stolen or forged tokens and assertions are a credential-access pathway into enterprise apps. |
| Recommendation — Map token theft scenarios to TA0006 and validate audience, binding, and issuer checks. | ||
Key terms
- Federation Assurance Level (FAL): FAL describes how strong the federated assertion is when identity crosses a trust boundary. It matters when one system relies on another to vouch for the user. In practice, FAL affects how much trust the receiving party can place in the assertion.
- Scim: System for Cross-domain Identity Management is the standard used to exchange user and group lifecycle data between an identity provider and an application. In production, the protocol only solves part of the problem. The harder issue is whether the implementation preserves attributes, order, and tenant scope consistently across real directory sources.
- Enterprise Connection: A per-customer trust relationship between an application and a customer identity provider. It is the operational unit that makes enterprise SSO manageable, because it scopes federation, provisioning, and configuration to a single organisation or domain.
- Proof-of-Possession: Proof-of-possession binds a token or credential to a specific key so possession of the token alone is not enough to use it. For AI agents, it reduces replay risk and helps ensure that an intercepted credential cannot be reused by a different actor.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org