What is Single Sign-On (SSO) and how does it work?

How does SSO work?

SSO is built on the concept of federated identity, the sharing of identity attributes across trusted but autonomous systems. When one system trusts a user, every other system in that trust relationship trusts them too. In practice this means creating a trust relationship between an identity provider (IdP), the system that creates, stores, and verifies user identities, and each service provider (SP), the app or website the user wants to reach. Importantly, an SSO service usually does not store user identities itself. It acts as an intermediary, checking a user's credentials against a separate identity management service, a bit like a librarian who looks up a book on your behalf without having the whole catalog memorized.

The National Institute of Standards and Technology (NIST) frames secure digital identity around three pillars: identity proofing, authentication, and federation. SSO maps directly onto this: users authenticate through a trusted source, and applications receive verified proof that the user is authorized. A typical sign-in flow looks like this:

1. The user tries to access a service provider (an app or website).
2. The SP redirects the request to the identity provider (the SSO system) for authentication.
3. If the user is not already signed in, they are prompted to log in once at the IdP.
4. The IdP validates the credentials and issues a signed authentication token.
5. The token is returned to the SP, and the user is granted access. For every other connected app, the token is checked and access is granted without another login.

How SSO authentication tokens work

The authentication token is what makes SSO possible. When a user signs in, the SSO service creates a token, a piece of digital data that says this user has been verified, and stores it either in the user's browser or on the SSO service's servers (sometimes called a central authentication service, or CAS, server). Whenever the user opens another app, that app checks with the SSO service, which passes the token over to confirm identity and let the user in.

For this to be trustworthy, the token has to be tamper-proof and speak a standard language. Tokens are digitally signed so the receiving app can verify they come from a legitimate source, much like event staff who recognize the exact stamp used at the entrance. The main token standard is Security Assertion Markup Language (SAML): just as web pages are written in HTML, many SSO authentication tokens are written in SAML. Modern flows also use OIDC and OAuth 2.0 tokens, for example a signed JSON Web Token, to carry identity information across domains, which is necessary because browsers enforce a same-origin policy that stops one domain from reading another domain's session data on its own.

SSO protocols and standards

Several protocols enable SSO, each suited to different environments. The table below compares the four you are most likely to encounter.

A useful distinction: OAuth authorizes (it grants access to a resource) while SAML and OIDC authenticate (they establish who the user is). In real deployments these are often used together. Beyond software protocols, hardware-based SSO also exists, such as smart cards that a user plugs in and unlocks with a PIN, which are highly secure but can be lost and are costlier to run.

Types of SSO deployment: On-premises vs. cloud

SSO solutions generally come in two deployment models. On-premises SSO runs on hardware or virtual machines that the organization installs and maintains itself. It offers complete control over the environment, which suits organizations with strict compliance or data-residency requirements, but it carries higher upfront costs and ongoing maintenance. Cloud-based SSO is delivered as software-as-a-service, fully hosted by the vendor. It lowers initial cost, removes the hardware burden, and scales on demand, in exchange for less direct control over the infrastructure. Many organizations get all of their IAM capabilities, SSO, adaptive MFA, and user directories, bundled together through an Identity-as-a-Service (IDaaS) offering.

A short history of SSO

SSO grew out of the on-premises identity tools that organizations used in the mid-to-late 1990s to connect their computers, networks, and servers. Back then, user identities were managed through systems like Microsoft's Active Directory (AD) and the Lightweight Directory Access Protocol (LDAP), with access secured by early on-premises SSO or Web Access Management (WAM) tools. As IT moved to the cloud, spread across many devices, and faced more sophisticated threats, those traditional tools struggled to keep up, which is what pushed SSO toward the cloud-delivered, standards-based model that dominates today.

Benefits of SSO

Organizations adopt SSO for a mix of productivity and security gains:

• Higher productivity and better user experience: One login unlocks every connected app, so users spend less time signing in and switching between tools.
• Fewer help desk tickets: With only one password to remember, password-reset requests drop sharply, freeing IT for higher-value work.
• Reduced attack surface: SSO curbs password fatigue and password reuse, two of the biggest sources of risk. It also means services store fewer credentials.
• Stronger, centrally enforced policy: MFA, password rules, and re-authentication can be enforced once at a single point rather than app by app.
• Simplified auditing and less shadow IT: Central authentication gives real-time visibility into who accessed what, when, and from where, and discourages the use of unsanctioned apps.
• A foundation for what comes next: SSO supports adding MFA, risk-based authentication, and eventually passwordless access.

Challenges and security risks of SSO

SSO is convenient and, done right, more secure, but it is not risk-free. The central concern is that SSO creates a single point of failure: if an attacker steals a user's SSO credentials, they gain access to every app that user can reach, and if the SSO system itself is compromised, every connected service is exposed. Verizon has reported that a large majority of attacks on web applications involve stolen credentials, which is exactly the scenario SSO can either mitigate or amplify depending on how it is secured.

Other challenges include dependency on a third-party service for authentication availability and security, implementation flaws such as misconfiguration, weak session management, or insufficient encryption, known vulnerabilities found in SAML and OAuth implementations, and app compatibility, since an app without real SSO support just becomes one more password. The recurring lesson is that SSO must never rely on a password alone. It should always be paired with MFA and sound identity governance.

Is SSO secure?

SSO can be highly secure, but its security depends entirely on how it is implemented. Best practice is to enforce MFA on all SSO logins, define clear per-user and per-group access policies, apply granular per-application controls, require device and location checks, keep detailed authentication logs, and add risk-based authentication that raises the bar when a sign-in looks unusual. A reputable provider will also ship built-in tooling to detect and block malicious login attempts. SSO on its own is not a security guarantee; SSO plus MFA, strong policy, and monitoring is.

How to implement SSO

Regardless of the specific protocol, an SSO rollout follows a consistent set of steps:

1. Integrate the identity provider: Set up and configure the IdP to store and manage user identities and credentials.
2. Register each service provider: Connect every app that will use SSO to the IdP, establishing mutual trust.
3. Set up the authentication flow: Implement the chosen protocol (SAML, OIDC, and so on) to handle the exchange of tokens and assertions.
4. Configure the user experience: Route users to the IdP for login when they try to reach any connected app.
5. Lock down security and compliance: Encrypt and sign assertions, enforce MFA, and meet applicable regulations.

Start with a pilot group to catch issues before a full rollout, keep the solution patched, and communicate clearly with users about what to expect.

SSO's role in IAM

SSO is one component of identity and access management, the broader discipline of controlling who can access what. SSO handles the authentication piece, verifying identity and granting the right level of access, and it should be integrated with access control tools, activity logs, and processes that monitor user behavior.

SSO vs. MFA

SSO and MFA are complementary, not competing. SSO simplifies access by letting one set of credentials unlock many apps, optimizing for convenience. MFA strengthens security by requiring additional proof of identity (a code, a push, a fingerprint) before granting access. SSO reduces the number of logins; MFA makes each login harder to fake. Used together, they balance a smooth experience with strong protection, which is why security teams recommend never deploying SSO without MFA.

SSO vs. federated identity

The two are related but operate at different scopes. SSO simplifies login within a single organizational domain, letting a user reach many apps with one set of credentials. Federated identity management (FIM) extends that trust across organizational boundaries, allowing secure access to resources owned by different companies or services without separate credentials for each, using standards like SAML and OAuth to establish cross-domain trust. SSO focuses on ease of access inside one domain; FIM focuses on interoperability between domains.

SSO vs. MFA at a glance

What to look for in an SSO provider

When evaluating SSO solutions, weigh a few capabilities:

• Security features: MFA integration, risk-based authentication, and granular per-application policies by user group, location, and device posture.
• Integration breadth: Support for existing cloud and on-premises apps and common protocols like SAML and OIDC.
• Ease of use: A clean, customizable dashboard and quick deployment.
• Scalability: High availability and strong service-level agreements (SLAs).
• Support quality: Availability for rollout and troubleshooting.
• Data sovereignty and compliance: Especially for European and regulated organizations, certifications such as SOC 2 and ISO confirm where and how identity data is handled.

Expert insight: SSO is an access control, and a prime detection signal

SSO is a preventive access control: it decides who gets in. That is essential, but it also concentrates risk into a single set of credentials, and attackers know it. A growing share of intrusions are identity-based, using valid SSO credentials, session hijacking, or MFA-fatigue attacks, which means the login looks legitimate to the SSO system even when it is not. Prevention alone cannot catch that. Detection and response on identity signals can, and that is where an SSO deployment needs a security operations layer behind it.

Sekoia treats identity and SSO telemetry as a first-class detection source rather than a box that is simply ticked. SSO and IdP logs, failed logins, impossible-travel events, unusual session behavior, and MFA anomalies are among the more than 300 integrations feeding the Sekoia unified SOC platform.

Inside Sekoia Defend, those identity events are correlated with endpoint, network, and cloud data and matched against roughly 1,000 detection rules mapped to MITRE ATT&CK, including credential-access and valid-accounts techniques that map exactly to how SSO gets abused. Detections are enriched by native Sekoia Intelligence Cyber Threat Intelligence (CTI) from an in-house Threat Detection & Research (TDR) team that actively tracks identity-based attacks, which keeps false positives low.

As a European vendor, Sekoia pairs this with a data sovereignty posture that large US identity providers rarely match, and with automated incident response that can disable a compromised session in minutes. Deploy SSO with MFA to control access, but put detection and response behind it, because a stolen SSO credential is a key to everything.

‍

Frequently asked questions about SSO