Single sign-on (SSO) is an authentication method that allows users to log in once with a single set of credentials and gain access to multiple applications without re-authenticating for each one.

‍

Main takeaways

• SSO reduces credential sprawl and password reuse by centralizing authentication through a trusted identity provider, making it easier to enforce consistent security policies across connected applications.
• Applications federated through SSO inherit the IdP's security controls: MFA policies, session management, and centralized provisioning and deprovisioning.
• SSO only governs the applications it's configured to protect. Shadow SaaS, personal-account signups, and applications that don't support SAML or OIDC fall entirely outside SSO's coverage.
• Offboarding through SSO disables the federated login—but doesn't revoke OAuth grants, API tokens, or access in applications employees connected outside the SSO umbrella.
• SSO is foundational to enterprise identity governance, but the gap between what SSO covers and what employees actually use is where much of the real identity risk accumulates.

What is SSO?

The problem SSO solves is credential sprawl. Without SSO, every application manages its own authentication: its own username, its own password policy, its own session management. For employees, this means dozens of credentials to manage and—predictably—password reuse across services. For IT, it means no central control point: provisioning a new employee requires touching every application individually, and deprovisioning requires the same.

‍

SSO creates a single point of authentication that all connected applications trust. An employee logs in once—typically through an identity provider like Okta, Microsoft Entra ID, or Google Workspace—and that authentication is accepted by every SAML- or OIDC-integrated application. The IdP becomes the arbiter of identity: if the IdP says the user is authenticated, the application accepts it. If the IdP account is disabled, the federated access disappears with it.

‍

How SSO works

At its core, SSO is a trust delegation model:

1. The user attempts to access an application.
2. The application—which doesn't manage its own credentials—redirects the user to the configured identity provider.
3. The identity provider authenticates the user (password + MFA, or an existing valid session).
4. The IdP issues a signed assertion (via SAML or an ID token via OIDC) confirming the user's identity and attributes.
5. The application validates the assertion and grants access.

The application trusts the IdP's assertion because the two have a pre-established trust relationship, typically configured through certificate exchange. The user's actual credentials never leave the IdP.

‍

The SSO coverage gap

SSO governance is bounded by what's configured in the IdP. Every application an employee accesses outside SSO—through a direct login, a personal account, or a tool that doesn't support SAML or OIDC—receives no SSO governance. No centralized MFA enforcement. No IdP-based deprovisioning. No session policy.

‍

For most organizations, this gap is substantial. Shadow SaaS applications adopted independently, AI tools connected through personal Gmail accounts, legacy applications that don't support modern federation standards, free-tier tools employees signed up for before IT had an equivalent offering—none of these appear in the IdP and none benefit from SSO controls.

‍

When an employee is deprovisioned through SSO, their federated access to IdP-connected applications stops immediately. Their accounts in shadow SaaS applications remain active. Their OAuth grants to third-party tools remain valid. Their sessions in applications they accessed outside SSO continue until those sessions expire on their own terms. SSO is a necessary foundation. Treating it as a complete offboarding solution is one of the most common identity governance gaps in practice.

‍

Learn how Nudge Security maps the full SaaS identity landscape—including what falls outside SSO coverage →