What is single sign on: SSO explained, including what it does not do
Single sign on, usually shortened to SSO, is an arrangement where a person authenticates once with a central identity provider and is then admitted to multiple separate applications without signing in again to each one. The applications trust the identity provider instead of holding their own passwords.
It is the reason an employee opens six tools in a morning and is challenged once, and the reason revoking one account can close all six.
What does single sign on mean?
Two roles matter, and mixing them up makes every SSO conversation harder than it needs to be.
- The identity provider (IdP) holds the accounts, performs the authentication, and issues a signed statement that a particular person has been authenticated. Entra ID, Okta, Ping and Google Workspace are common ones.
- The service provider (SP) is the application the person is trying to reach. In OpenID Connect terms it is called the relying party. It holds no password. It verifies the signed statement and admits the user.
Everything else in SSO is a detail of how that statement travels and how the receiving side checks the signature.
Try Venta Capture on your own process
Build one flow for your highest-volume case type. Free, no credit card.
How does SSO work?
A user reaches the application and is redirected to the identity provider. If they already have a valid session there, nothing is asked of them. If not, they authenticate, with a second factor where policy requires it.
The identity provider redirects them back carrying a signed token. The application validates the signature against the provider's published key, checks the audience and expiry, reads the user's identifier and attributes, and starts a local session. The whole exchange usually takes less time than the page render.
SAML or OIDC: the two protocols you will meet
- SAML 2.0 was approved as an OASIS Standard in March 2005. It is XML based, and the signed statement is called an assertion. It remains the default in enterprise procurement, and most corporate identity providers still lead with it.
- OpenID Connect is newer. The OpenID Foundation published OpenID Connect Core 1.0 as a final specification in February 2014, defining an identity layer on top of OAuth 2.0. It is JSON based, the token is a JWT called an ID token, and it handles mobile and single page applications far more comfortably than SAML does.
- Which to ask for. If the vendor supports both, take OIDC for new work. If your identity provider team has one working pattern already, use theirs, because a second pattern doubles the number of things that break at renewal.
Note that OAuth 2.0 on its own is not SSO. It is an authorisation framework for granting an application access to a resource. Using it as a login mechanism without the OIDC layer is a well known source of subtle security bugs.
What SSO does and does not do for security
SSO centralises the password problem. It does not eliminate it. The credential still exists, it is still phishable, and it now unlocks considerably more than it did before. Verizon's 2025 Data Breach Investigations Report found compromised credentials were an initial access vector in 22% of the breaches it reviewed.
What SSO genuinely gives you is worth having: one place to enforce multi factor authentication and conditional access, one audit log of authentication events, and an offboarding action that actually takes effect everywhere. What it does not give you:
- Protection against phishing on its own. A stolen SSO credential, or a stolen session token, is more valuable than a single application password, not less. Phishing resistant factors are a separate decision.
- Immediate revocation. Disabling the account stops new sign ins. Sessions already issued in each application typically live until they expire, and SAML Single Logout is inconsistently implemented in practice.
- Any answer about permissions. SSO says who someone is. What they may then do is role based access control, and it is configured separately.
- Automatic account lifecycle. Provisioning and deprovisioning of accounts is usually SCIM, a different protocol that has to be enabled on its own.
SSO explained: an example from a rollout
An operations team adds a visual capture tool used by forty reviewers. Rather than forty new passwords, the tool is registered as a service provider against the company identity provider, and access is granted through an existing directory group.
A reviewer leaves three months later. Their directory account is disabled on their last day, and the fortieth password nobody would have remembered to remove no longer exists.
What to check before you turn it on
- The tier it sits behind. Some vendors sell SSO only on an enterprise plan. Find out early, because it changes the cost case.
- Group and attribute mapping. Which directory attribute becomes the identifier, and whether group membership can drive roles in the application.
- The break glass account. One local administrator account that does not depend on the identity provider, protected properly. Federation outages happen, and locking your own administrators out of a system during one is avoidable.
- Certificate expiry. SAML signing certificates expire, usually at an inconvenient moment. Put the date in a calendar owned by a team, not a person.
- Where the audit log lives. The identity provider records the authentication. The application records what was then done. You will want both, and the same reasoning applies to chain of custody wherever evidence is involved.
SSO is one of the standard connections in any integration conversation with a vendor, alongside the API and the queue the work lands in, which is covered under shared inbox.
Try Venta Capture on your own process
Build one flow for your highest-volume case type. Free, no credit card.