Single Sign-On (SSO)

How Single Sign-On works

SSO relies on a trust relationship between two parties: an identity provider (IdP) that authenticates users and holds their credentials, and one or more service providers (SPs) — the applications the user wants to reach. The user authenticates against the IdP exactly once per session; every connected application then accepts the IdP's word as proof of identity.

The mechanics differ by protocol, but the shape is consistent:

• The user requests access to an application (the service provider).
• The application redirects the unauthenticated user to the identity provider.
• The IdP authenticates the user — password, MFA, passkey, or an existing session — and issues a signed token (OIDC) or assertion (SAML).
• The application validates the signature against the IdP's published keys and grants access without ever handling the user's password.

Because the application trusts a cryptographically signed statement from the IdP rather than verifying credentials itself, the password exists in one place only. This is the central trade-off of SSO: fewer attack surfaces for the password, but a single, high-value point of trust.

SAML 2.0 and OpenID Connect

Two protocols dominate enterprise SSO. SAML 2.0 is the older, XML-based standard, well established for web applications and common in business-to-business and workforce scenarios. OpenID Connect is a modern identity layer built on OAuth 2.0, using JSON Web Tokens (JWTs) over REST, and is the default for newer applications, mobile clients, and API-driven architectures.

Both achieve the same outcome — one authentication, many applications — and many identity providers support both so that legacy and modern applications can share a single login.

Why organizations adopt SSO

SSO is one of the highest-leverage controls in identity and access management, for reasons that are both security- and operations-driven:

• Fewer passwords, fewer weak passwords. Users memorize one strong credential instead of reusing a weak password across dozens of systems, shrinking the attack surface for credential-based compromise.
• Centralized authentication policy. MFA, password strength, session lifetime, and conditional access are enforced once at the IdP and apply to every connected application uniformly.
• Faster onboarding and deprovisioning. Disabling a single IdP account revokes access to every connected application at once — critical when an employee leaves or an account is compromised. Without SSO, deprovisioning means hunting down accounts in each system individually.
• Visibility into access. A central IdP produces a single log of authentication events across the application estate, rather than fragmented logs in each system.

These benefits are why SSO is a baseline expectation in enterprise security and a common requirement in compliance frameworks.

The risks and limits of SSO

SSO concentrates trust, and concentration cuts both ways. The same architecture that lets one disabled account revoke all access also means that a single compromised SSO account can unlock everything connected to it. If an attacker phishes a user's IdP credentials and bypasses or defeats MFA, every downstream application is reachable. This makes the identity provider the most valuable target in the environment and the reason MFA, phishing-resistant factors, and conditional access at the IdP are non-negotiable.

The more fundamental limit is one of scope. SSO governs authentication — who gets in — and nothing more. Once the IdP issues a token and a session is established, SSO has done its job and steps aside. It does not see what the user does inside the application, what data they access, what they type, or what an application does on their behalf. SSO secures the front door; it has no view of the rooms beyond it.

Why SSO is not enough for AI

This front-door-only scope is exactly where SSO falls short in an AI-driven environment. SSO can decide whether a user may open a sanctioned AI tool. It can gate access to an approved chatbot, an internal AI assistant, or a coding copilot behind a corporate login. That is valuable — it keeps unapproved identities out and ties usage to a known user.

But once the session is live, SSO is blind to everything that matters about AI risk:

• It cannot see the prompts a user submits, so it cannot tell whether a customer list or confidential contract is being pasted into the model.
• It cannot inspect the completions the model returns, so it cannot catch regulated data surfaced from a connected system.
• It cannot govern agent actions, so when an AI agent calls an external tool or API on the user's behalf, SSO has no record and no control.
• It cannot distinguish which model or what data is in play within an authorized tool — every action inside the session is, to SSO, simply "an authenticated user."

In other words, SSO answers "is this a legitimate user?" but never "is this a safe AI action?" Authentication is necessary, but post-authentication AI activity is where data exposure, prompt injection, and ungoverned agent behavior actually occur — and that activity is invisible to the login layer.

Questions SSO answers — and the ones it leaves open

• Is this a legitimate, authenticated user? — Yes, SSO answers this directly.
• Should this user be able to open this AI tool at all? — Yes, via the IdP's access policy.
• What did the user submit to the AI model in this session? — No. Out of scope.
• Did the model return sensitive data, and to whom? — No. Out of scope.
• What did an AI agent do after the user logged in? — No. Out of scope.

The first two are authentication questions. The last three are governance questions that begin precisely where SSO ends.