SSO (single sign-on) is a way of logging in where one sign-in with your organization's account gives you access to many separate applications. Users authenticate once with the organization's identity provider (IdP), such as Microsoft Entra ID, Okta or Google Workspace, and are then signed in to connected applications without typing another password. The common protocols are SAML 2.0 and OpenID Connect (OIDC).
In SSO, each connected application is called a service provider (SP) or relying party. The application trusts the identity provider to confirm who the user is, so it never needs to store or check that user's password itself.
Why it matters
- Security: fewer passwords to steal or reuse, with MFA and password rules enforced in one place.
- Offboarding: disabling one account removes access to every connected app at once.
- Convenience: fewer logins and fewer password-reset tickets.
- Visibility: sign-ins are logged centrally at the identity provider.
SSO is often paired with automated user provisioning, for example SCIM, which creates, updates and removes accounts in each app from the central directory.
How an SSO sign-in works (SAML example)
- The user opens the application and chooses to sign in with their work account.
- The application redirects them to the identity provider.
- The IdP authenticates them, often with MFA, or recognizes an existing session.
- The IdP sends back a digitally signed assertion saying who the user is, and sometimes their groups.
- The application verifies the signature, signs the user in and applies their roles. It never sees the password.
SAML vs OpenID Connect vs OAuth 2.0
| Item | SAML 2.0 | OpenID Connect (OIDC) | OAuth 2.0 |
|---|---|---|---|
| Main purpose | Sign-in (authentication) for web apps | Sign-in built on top of OAuth 2.0 | Delegated access (authorization), not sign-in by itself |
| Token format | XML assertion | JSON Web Token (ID token) | Access token (format varies) |
| Typical use | Enterprise and older business apps | Modern web and mobile apps | Letting one app call another app’s API |
| Common in SSO? | Yes | Yes | Only as the base for OIDC |
SSO vs MFA vs password managers
SSO decides where you sign in: once, at the identity provider. Multi-factor authentication (MFA) decides how strongly you prove who you are. A password manager stores a separate password for each app. Most organizations combine SSO with MFA at the identity provider, so every connected app inherits the stronger sign-in.
Common mistakes with SSO
- Leaving local passwords active. If users can still sign in with an old app password, disabling the SSO account does not fully remove access.
- Weak protection on the IdP. It becomes the key to everything, so enforce strong MFA there.
- No break-glass account. Keep a secured emergency admin login in case the identity provider is unavailable.
- Mapping roles by hand. Use groups from the directory so role changes follow the person automatically.
