SSO

In short

SSO stands for single sign-on. It's the arrangement by which a person authenticates once with an identity provider and the rest of the applications accept the result of that authentication instead of asking for credentials again.

What travels between systems isn't the password. It's a signed assertion that someone authenticated, with what method and when. That assertion is the whole mechanism.

How a session that opens several applications is sustained

There are three pieces, and it's worth naming them separately, because most SSO problems live in the relationship between them.

• The identity provider — the system that authenticates the person and issues the assertion. It's the only one that sees the authentication factor.
• The application — the system that needs to know who logged in. It doesn't authenticate: it validates the assertion's signature and trusts its content.
• The session — the period during which that assertion keeps being accepted without repeating authentication. It defines how long the convenience lasts and how long the risk lasts.

There are two standards that formalize the exchange. SAML 2.0 transports assertions in XML and is the one that dominates corporate environments with applications installed years ago. OpenID Connect is an identity layer built on top of OAuth 2.0 that transports an identity token and is the one that dominates new web and mobile applications.

OAuth 2.0 is not an authentication protocol

It's the most frequent confusion in the category and it produces insecure integrations, so it's worth clearing up.

OAuth 2.0 solves authorization delegation: it lets an application access a resource on a person's behalf, without knowing their credentials. It answers the question of what a system can do.

OpenID Connect adds the missing piece on top: an identity token that asserts who the person is and how they authenticated. It answers the question of who logged in.

Using an OAuth access token as if it were proof of identity is treating a permission as a credential. They're different things, and the standard separated them on purpose.

SSO reduces the number of authentications, it doesn't strengthen them

A well-implemented SSO improves the experience and improves control: there's a single place where access policy is applied, a single place to revoke it, and a single record of who accessed what.

It also concentrates risk, by definition. If the identity provider's authentication relies on a reused password, that single point opens the entire application portfolio. It's what turns a successful credential stuffing attack against the identity provider into a full-scope incident instead of a single-application one.

Hence the practical rule: SSO gets implemented alongside MFA on the identity provider, not in its place. Convenience comes from SSO. Strength comes from the factor.

Two more decisions that often go unowned and end up deciding the outcome:

• Session duration — a long session is convenient and is also a long window for whoever steals a token. It's the parameter that adaptive authentication adjusts based on the operation's risk instead of fixing it the same for everything.
• Federated logout — logging out of one application doesn't log out of the identity provider or the others, unless federated logout is implemented. It often isn't.

Corporate SSO and social login are not the same arrangement

Both use the same mechanics and serve different interests.

In corporate SSO, the organization controls the identity provider. It defines the policy, revokes access when someone leaves, and keeps the record.

In login with a social network or a consumer account, the identity provider is a third party with its own rules. The organization delegates the quality of the authentication to it, and with it, the quality of the relationship: it inherits data verified by someone else without seeing how it was verified. For a digital identity that later has to sustain a regulatory obligation, that inheritance isn't enough.