What Is Single Sign-On (SSO)? How SSO, SAML and OIDC Work in 2026

Short answer: single sign-on (SSO) lets a person log in once to a trusted identity provider and then open many separate applications without entering a password for each one. The identity provider (IdP) proves who the user is to each application (the service provider, or SP) using a standard protocol, usually SAML 2.0 or OpenID Connect (OIDC). OAuth 2.0 is related but is an authorization protocol: it grants an app access to data, and OIDC adds the login layer on top of it. SSO reduces password sprawl and gives IT one place to enforce MFA and cut off access, but it also concentrates risk in the IdP, so it has to be paired with strong authentication.

This guide explains how SSO works step by step, how SAML, OIDC and OAuth differ, the types of SSO you will run into, the real downsides, and a practical rollout plan. If you are already comparing vendors, jump to our guide to the best SSO software.

What is single sign-on (SSO)?

Single sign-on is an authentication pattern where one login session at a central identity provider is reused to sign the user into many applications. Instead of each app storing its own password for the user, the apps trust the IdP. When a user opens an app, the app hands the login job to the IdP, the IdP checks the user (password, passkey, MFA prompt, device checks), and then sends the app a signed statement that says, in effect, “this is Priya from Finance, she authenticated a minute ago, here are her attributes”.

Three roles show up in every SSO setup:

• The user, who wants to reach an application.
• The identity provider (IdP), which holds or connects to the user directory and performs authentication. Examples include Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin and the open-source Keycloak.
• The service provider (SP), also called the relying party: the app the user is trying to open, such as a CRM, HR system or cloud console.

SSO is one part of the broader discipline of identity and access management (IAM), which also covers provisioning, access reviews, privileged access and policy.

How does SSO work?

The exact messages differ by protocol, but a typical browser-based, SP-initiated SSO login follows the same eight steps:

1. The user opens an app (the SP) and has no session there yet.
2. The app redirects the browser to the IdP with an authentication request. It identifies itself and says where the answer should be sent.
3. The IdP checks for an existing session. If the user already signed in to the IdP earlier today, they may not be prompted at all. That is the “single” in single sign-on.
4. If there is no session, the IdP authenticates the user: password or passkey, then MFA, plus any conditional access rules (device health, location, risk score).
5. The IdP issues a signed assertion or token: a SAML assertion (XML) or an OIDC ID token (a JSON Web Token). It contains the user identifier and attributes such as email, groups or roles.
6. The browser carries that response back to the app.
7. The app validates the signature using the IdP’s public certificate or keys, checks the audience, timestamps and replay protections, and maps the user to a local account.
8. The app creates its own session and lets the user in. Opening the next app repeats steps 1 to 8, but step 3 now succeeds silently.

Two setup details matter in practice. First, the IdP and each SP exchange configuration once (metadata, certificates, redirect URLs, client IDs). Second, SSO handles login, not account creation or removal. That is the job of provisioning, usually through SCIM, which creates, updates and deactivates accounts in each app when HR or IT changes the user in the directory.

SAML vs OIDC vs OAuth: what is the difference?

These three names get used interchangeably, which causes a lot of confused buying conversations. The short version: SAML and OIDC are for authentication (proving who someone is); OAuth 2.0 is for authorization (letting an app act on someone’s behalf).

Which should you use? Use whatever the application supports well. Most enterprise SaaS tools offer SAML, and many newer ones offer OIDC too. For apps you build yourself, OIDC is usually the simpler choice because libraries are widely available and tokens are easy to handle in JavaScript and mobile clients. A good IdP supports both, plus SCIM for provisioning.

You may also meet older or specialised protocols: Kerberos and integrated Windows authentication for on-premises Active Directory apps, WS-Federation in older Microsoft environments, LDAP binds for legacy systems, and RADIUS for network and VPN gear. Modern IdPs typically bridge several of these.

What are the main types of SSO?

• Workforce (enterprise) SSO. Employees and contractors sign in once to reach company apps. This is what most people mean by “SSO software”.
• Customer SSO and social login. Your customers sign in to your apps with one account, or with Google, Apple or Microsoft. This is part of customer identity and access management (CIAM); see CIAM vs IAM for how the two differ.
• B2B federation. Your app lets each business customer connect their own IdP, so their staff log in with company credentials. SaaS vendors often add this with tools such as WorkOS or a CIAM platform.
• SP-initiated vs IdP-initiated. SP-initiated starts at the app (the flow above). IdP-initiated starts from the IdP’s app dashboard. SP-initiated is generally considered safer and is more common in modern setups.
• Password-vaulting SSO. For apps that support no federation protocol, some IdPs and password managers store and replay credentials. It is convenient but weaker than true federation, because a password still exists and can be phished or reused.

What are the benefits of single sign-on?

• Fewer passwords to steal or reuse. Users keep one strong credential (ideally a passkey or MFA-backed login) instead of dozens of weak ones.
• One place to enforce MFA and conditional access. Rules apply to every connected app at once, including apps that have weak or no MFA of their own.
• Faster offboarding. Disabling one IdP account blocks new logins to every federated app. Pair it with SCIM so the app accounts are also deactivated.
• Fewer help desk tickets. Password resets are one of the most common IT requests; SSO plus self-service reset reduces them.
• Central audit trail. Sign-in logs for all federated apps live in one system, which helps investigations and audits (SOC 2, ISO 27001, HIPAA).
• Better user experience. People stop juggling logins and spend less time locked out.

What are the disadvantages and risks of SSO?

SSO is a net security gain for most organisations, but it changes the shape of your risk. Plan for these:

• A single point of compromise. If an attacker takes over an IdP session or admin account, they may reach every connected app. Mitigate with phishing-resistant MFA (FIDO2 security keys or passkeys) for admins and high-risk users, short admin sessions, and alerts on admin changes.
• A single point of failure. If the IdP is down, logins to everything can stop. Ask vendors about their availability commitments and keep documented break-glass accounts that do not depend on the IdP.
• Session and token theft. Attackers increasingly steal session cookies after login. Shorter session lifetimes, device-bound sessions where supported, and re-authentication for sensitive actions help.
• Incomplete coverage. Apps that do not support SAML or OIDC, or only support it on an expensive plan, leave gaps. Keep a password manager for the remainder; see our guide to the best password managers for business.
• The “SSO tax”. Many SaaS vendors put SAML SSO only on their top plans, which can raise the total cost of adopting SSO across your stack.
• Logout is harder than login. Single logout across many apps is unreliable in practice, so rely on deprovisioning and session limits, not on logout alone.

SSO vs MFA vs password manager: which do you need?

Most organisations need all three: SSO in front of every app that supports it, strong MFA on the SSO login itself (see our guide to the best MFA software), and a password manager for the long tail.

Is SSO the same as IAM?

No. SSO is one capability inside identity and access management. IAM also includes the user directory, provisioning and deprovisioning, role and group management, access requests and reviews (identity governance), privileged access management for admin accounts, and policy enforcement. Many IAM platforms bundle SSO, which is why the terms blur. For a full breakdown, read What Is Identity and Access Management? and our comparison of IAM tools.

How do you implement SSO? A step-by-step rollout

1. Inventory your apps. List every SaaS and internal app, its owner, how many users it has, and whether it supports SAML, OIDC and SCIM (and on which plan).
2. Pick your identity provider. If you already run Microsoft 365 or Google Workspace, start by checking what their identity layer covers. Compare dedicated IdPs if you need broader app catalogues, stronger lifecycle automation or mixed operating systems.
3. Clean up the directory. Remove stale accounts, standardise usernames and emails, and define groups that map to roles. SSO amplifies whatever is in the directory, good or bad.
4. Set authentication policy first. Require MFA for everyone, phishing-resistant methods for admins, and conditional access rules for unmanaged devices or risky sign-ins.
5. Connect high-value apps first. Email, file storage, CRM, finance, HR and cloud consoles. Turn on SCIM where available so joiners and leavers flow automatically.
6. Pilot with one team, then expand in waves. Keep a rollback path (local admin login) until each app is proven.
7. Enforce SSO in each app once users are migrated, so local passwords stop working.
8. Create and test break-glass accounts for the IdP and critical apps, stored securely and monitored.
9. Review quarterly. Check app coverage, admin roles, stale accounts and policy exceptions.

Which metrics show SSO is working?

• App coverage: the share of apps (and of users per app) behind SSO.
• Provisioning coverage: the share of SSO apps that also use SCIM or another automated deprovisioning path.
• MFA enrolment and the share of users on phishing-resistant methods.
• Password reset tickets per month, before and after rollout.
• Time to revoke access when someone leaves.
• Orphaned accounts found in access reviews.

How to choose an SSO provider

Start with what you already own, then test the gaps. The questions that separate providers are: how many of your apps have pre-built SAML, OIDC and SCIM connectors; how strong and flexible the MFA and conditional access options are; whether it manages devices and directories you run (Windows, macOS, Linux, on-premises Active Directory); how clear the admin experience and logs are; and how the vendor prices (usually per user per month, with some features in add-ons). Our guide to the best SSO software compares the main options, and the SSO platforms category lists more. If you are weighing a move away from Okta, see Okta alternatives.

Frequently asked questions about single sign-on