TL;DR: Single sign-on centralizes authentication through a trusted identity provider, and the article explains how SAML and OIDC differ for enterprise app integration, how JIT and SCIM affect provisioning, and why replay protection, logging, and authorization still matter according to WorkOS. The real lesson is that SSO simplifies login but does not remove identity governance responsibility.
At a glance
What this is: This is a guide to how SSO works for enterprise apps, with a clear comparison of SAML and OIDC and a warning that authentication alone does not cover provisioning, logging, or authorization.
Why it matters: IAM and application teams need to treat SSO as a control plane for authentication, not a complete identity control model, because enterprise access still depends on provisioning, session handling, and downstream authorization.
Context
Single sign-on is a delegated authentication pattern, not a full identity governance programme. A user authenticates once through an identity provider, then presents a signed assertion or token to each application that trusts that provider. The security value comes from centralising login decisions, but the governance burden shifts to how the application validates those claims, provisions users, and enforces access after login.
For enterprise app teams, the practical question is not whether SSO works, but where its boundaries begin and end. SAML and OIDC solve the handoff between identity provider and service provider in different ways, yet both still leave replay protection, lifecycle control, and application-level authorization as separate responsibilities. That makes SSO a foundation for IAM design, not a replacement for it.
Key questions
Q: What breaks when an app relies on SSO without lifecycle provisioning?
A: Authentication may still work while access outlives employment status, role changes, or offboarding events. Without lifecycle provisioning, the app can keep accounts active long after the IdP relationship has changed. That creates a governance gap between login and entitlement removal, especially in enterprise apps where access needs to follow joiner, mover, and leaver changes.
Q: When is SCIM better than JIT provisioning for enterprise access?
A: SCIM is better when access must change as the source of truth changes. It is the stronger choice for joiner, mover, and leaver governance because it can update or remove accounts after first login. JIT is useful for simplicity, but it can leave access state lagging behind identity changes if the application does not have additional governance controls.
Q: How should security teams validate that SSO is truly enforced?
A: Validate SSO at the relying application, not only in the identity provider. Check for local login, password fallback, test modes, and mixed-auth states, then correlate application audit logs with IdP sign-ins. If a user can authenticate without the IdP being involved, SSO is available but not enforced.
Q: What is the difference between SAML SSO and OIDC for enterprise authentication planning?
A: SAML SSO is often used to satisfy enterprise federation requirements in mature business environments, while OIDC is widely used for modern web and application authentication flows. The practical distinction is not just protocol format but integration fit. Security teams should choose the option that aligns with customer identity infrastructure, product architecture, and support expectations.
Technical breakdown
How SSO delegates trust to the identity provider
SSO works by moving the primary authentication decision to an identity provider and then letting the application consume a signed proof of identity. In SAML, that proof is an XML assertion carried through browser redirects and form posts. In OIDC, the proof is usually an ID token, often accompanied by an access token, delivered through OAuth 2.0 based flows. The application must validate signature, issuer, audience, expiry, and nonce or equivalent replay controls before trusting the claim. The security model depends on the app verifying the token correctly, not just receiving it from a trusted provider.
Practical implication: Validate every assertion or token at the application boundary, including signature, expiry, issuer, audience, and replay protections.
SAML vs OIDC for enterprise app integration
SAML and OIDC both support delegated authentication, but they fit different integration surfaces. SAML is older, XML-based, and common in enterprise browser flows where legacy identity providers still dominate. OIDC is JSON-based, easier to work with in modern web and mobile apps, and aligns more naturally with API-friendly architectures. The choice is therefore less about which protocol is universally better and more about the identity context you must support. App teams often need both because enterprise customers bring different identity estates and procurement expectations.
Practical implication: Support both protocols where enterprise customer mix or IdP diversity makes a single standard unrealistic.
Why JIT provisioning is not the same as lifecycle control
JIT provisioning creates an account at first login, which is efficient but only addresses the initial onboarding moment. SCIM pushes identity data from the IdP into the app, so changes in group membership or employment status can update or remove access automatically. That distinction matters because authentication alone does not remove access when a user leaves. If an app relies only on JIT, the account may remain valid long after the IdP relationship has changed, creating a lifecycle gap that sits outside the login flow itself.
Practical implication: Use SCIM where access revocation, role drift, and offboarding need to track identity changes beyond first login.
Breaches seen in the wild
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SSO reduces password exposure, but it does not collapse the identity governance problem. Centralised login removes one common attack path, yet the application still has to decide what to trust, for how long, and under what conditions. That means SSO is an authentication control, not a complete access governance model. Practitioners should treat the IdP as the source of proof and the app as the source of enforcement.
SAML and OIDC create different integration risks, but the governance question is the same. SAML environments often carry heavier configuration and legacy integration risk, while OIDC introduces token handling and API-facing validation concerns. The protocol choice changes the mechanics, but not the need for claim validation, authorization, and lifecycle coordination. The enterprise issue is whether the app team can govern trust boundaries consistently across both.
JIT provisioning creates a convenience window that can become an access persistence window. If first-login account creation is the only lifecycle event the app understands, then joiner and leaver changes remain external to the application. SCIM narrows that gap by making the IdP drive updates, but the governance model still depends on whether the app actually consumes and acts on those updates. Identity teams should judge SSO by lifecycle coverage, not login simplicity.
Identity provider trust must be paired with application-level authorization. A valid SSO assertion proves the user authenticated, but it does not prove the user should reach a particular resource or function. That is why roles, groups, and permission mapping remain essential after login. The implication for enterprise app teams is straightforward: authentication can be centralised, but authorization cannot be outsourced away.
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
Session trust is not lifecycle trust: enterprise teams often conflate successful login with safe access governance, but SSO only establishes the initial trust handoff. What matters next is whether the application can consume revocation, role change, and offboarding signals with the same reliability as the login flow.
Protocol choice increasingly reflects integration reality rather than ideology. SAML remains embedded in many enterprise environments, while OIDC fits modern application and API patterns, so teams need a governance model that can support both without creating duplicate authorization logic.
Where apps use JIT without a stronger offboarding path, access can persist beyond the identity event that justified it. That is why provisioning, session handling, and authorization deserve as much attention as the SSO handshake itself.
For practitioners
- Validate every SSO assertion at the app boundary Check signature, issuer, audience, expiry, and nonce handling before creating a session or trusting returned identity claims.
- Support both SAML and OIDC where enterprise demand requires it Plan for customer identity diversity, since legacy IdPs and modern cloud IdPs often coexist in the same buying motion.
- Use SCIM for lifecycle-driven access changes Prefer SCIM when deprovisioning, group updates, and role drift must be reflected automatically after joiner and leaver events.
- Separate authentication from authorization decisions Map SSO assertions to roles or groups, then enforce application permissions independently for sensitive workflows and data access.
Key takeaways
- SSO centralises authentication, but the application still has to validate tokens, enforce authorization, and manage lifecycle changes after login.
- SAML and OIDC solve the same trust problem through different mechanics, so enterprise app teams often need to support both.
- JIT simplifies first login, but SCIM is the control that closes the gap between authentication and offboarding.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSO token and assertion handling depends on authenticator lifecycle and validation controls. |
| IA-9 — Service Identification and Authentication | Enterprise apps and identity providers exchange authenticated assertions and tokens across trust boundaries. | |
| Recommendation — Apply IA-5 to manage assertion lifetimes, token handling, and revocation boundaries for SSO sessions. Use IA-9 to authenticate service-to-service SSO exchanges and validate claims at the application edge. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article stresses that SSO must be paired with role and permission enforcement after login. |
| Recommendation — Map SSO identities to entitlements and enforce application authorization independently of authentication. | ||
| NIST SP 800-63 | SP 800-63C — Federation | SAML and OIDC are federation mechanisms for delegated authentication between IdP and service provider. |
| Recommendation — Align federation design with SP 800-63C and validate trust, claims, and lifecycle assumptions. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | OIDC and token-based flows require strong authentication validation to avoid assertion misuse. |
| Recommendation — Treat SSO token handling as authentication control and reject expired or replayed assertions. | ||
Key terms
- Single Sign On: Single Sign On is a login method that lets a user access multiple applications with one authenticated session. Technically, an identity provider issues a trusted authentication assertion or token after the user signs in, and connected services accept that proof instead of requiring separate passwords for each application.
- SAML: Security Assertion Markup Language is an XML-based federation protocol used to pass signed identity assertions between an identity provider and a relying party. It remains common in enterprise SSO, but its certificate-driven trust model can make configuration and rotation more operationally demanding.
- OpenID Connect: OpenID Connect is an identity layer built on OAuth 2.0 that lets applications authenticate users with compact tokens and standardised key discovery. It is widely used for modern web, mobile, and API-driven systems because it reduces integration overhead compared with older federation patterns.
- 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.
Deepen your knowledge
NHI governance, IAM, and identity lifecycle management 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 access governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org