Single Sign-On (SSO)

Single sign-on (SSO) lets a user sign in once, with one identity, and then open many applications without signing in to each one separately. Instead of every app keeping its own usernames and passwords, the apps trust a central identity provider (IdP), which verifies the user and passes each app a signed confirmation of who they are. For users it means fewer passwords; for IT it means one place to enforce sign-in policy and remove access.

At a glance

• Apps hand sign-in to a central identity provider, which confirms the user’s identity to each app through a signed token or assertion.
• Common standards are SAML and OpenID Connect; Kerberos provides SSO inside many Windows networks.
• MFA and conditional access can be enforced once at the IdP rather than in every app.
• SSO concentrates risk at the identity provider, so its sign-in needs strong protection.
• SSO handles sign-in; creating and removing accounts in each app is usually done separately, often with SCIM.

What problem it solves

A mid-sized company can easily use dozens or hundreds of SaaS apps. If each has its own password, users reuse passwords or write them down, the help desk spends time on resets, and every app sets its own sign-in rules. When someone leaves, IT has to remember every account they had, and forgotten accounts stay active.

SSO puts sign-in in one place. Users remember one strong credential, ideally backed by passkeys or other phishing-resistant MFA. IT sets MFA, device and location rules once and can see sign-ins across apps. Disabling a user at the identity provider blocks new SSO sign-ins to connected apps, which makes offboarding faster, though existing app sessions and any local accounts still need to expire or be removed as part of a wider joiner-mover-leaver process.

How it works

1. The user opens an app. The app, called the service provider, doesn’t ask for a password; it redirects the user to the identity provider.
2. The identity provider authenticates the user. It checks the user’s credentials and MFA, and can apply conditional access rules such as requiring a managed device. If the user already has an active session at the IdP, this step may be silent.
3. The IdP sends a signed response. Using SAML or OpenID Connect, it returns a signed assertion or token naming the user and attributes such as email address and groups.
4. The app trusts it. The app checks the signature and starts a session, without the user entering another password.
5. Other apps reuse the session. When the user opens another connected app, the IdP recognizes the existing session and signs them in.

OAuth 2.0 often appears alongside these standards. It authorizes apps to access data or APIs on a user’s behalf; OpenID Connect adds sign-in on top of it. Account creation and removal is a separate job: some apps create accounts on first sign-in, and SCIM can keep accounts and groups in sync with the identity provider.

When it matters for buyers

• When SaaS use grows quickly. Each new app is easier to secure if SSO is a purchase requirement from the start.
• When auditors, insurers or customers ask about access control. Central MFA, sign-in logs and fast offboarding are common questions.
• When integrating an acquisition. Bringing a new team onto your identity provider, or federating with theirs, is often an early step.
• When buying SaaS. Some vendors include SSO only in higher-priced plans, which can change the real cost of the app.
• When reviewing your identity provider. Availability, admin protection and recovery procedures matter more once every app depends on it.

Questions to ask vendors

For SaaS vendors:

• Do you support SAML or OpenID Connect, and on which plans?
• Do you support SCIM for creating and removing accounts?
• Can we require SSO for all users, including admins, and turn off local passwords?

For identity providers:

• Which apps have prebuilt integrations, and how do we connect ones that don’t?
• Which MFA methods, including passkeys and hardware keys, can we require for which users?
• What availability do you commit to, and what happens to signed-in users during an outage?
• What sign-in logs do we get, for how long, and can they go to our SIEM?

How it differs from MFA

Multi-factor authentication (MFA) is about how strongly someone proves who they are at sign-in, by requiring more than one factor such as a password plus a passkey or authenticator app. SSO is about how many times they have to sign in: once, at the identity provider, for many apps. They solve different problems and work best together. A password manager is different again: it stores separate credentials for each app and fills them in, but each app still has its own password. For identity-driven access controls across web, SaaS and private apps, see our Security Service Edge (SSE) overview.

Problems this helps with

• Employees juggling dozens of passwords and reusing them
• Password reset tickets eating up help desk time
• Former employees still have access to SaaS apps after they leave
• No single place to enforce MFA across all our apps