Home / Glossary / SSO (Single Sign-On)
Tech & ITSSO (Single Sign-On)
By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site
Sign in once through an identity provider and get into many work apps.
An identity provider such as Microsoft Entra ID (formerly Azure Active Directory) or Okta checks who you are once, then vouches for you to each app through a standard such as Security Assertion Markup Language (SAML) or OpenID Connect. IT gets one account to disable when someone leaves. The flip side: one stolen login unlocks everything, so pair SSO with multi-factor authentication (MFA).
The intuition
Single sign-on means you prove who you are once, to one trusted service, and every other application takes that service's word for it. The trusted service is the identity provider: Microsoft Entra ID, Okta, Google Workspace or Ping. The applications, from the risk dashboard to the HR portal to Slack, are service providers that no longer hold your password at all. When you open the dashboard, it sends you to the identity provider, which either recognises your existing session or asks you to log in, and then hands the dashboard a signed statement that says who you are and which groups you belong to.
Two standards carry that statement. SAML, Security Assertion Markup Language, is the older one, sending a signed XML assertion through the browser; most enterprise software supports it. OpenID Connect is the newer one, built on OAuth 2.0, sending a signed JSON Web Token, and it is what consumer logins such as Sign in with Google use. In both cases the application verifies the signature with the identity provider's published public key, so a forged statement is rejected, and the application never sees the password.
The gain is control. A new joiner gets every application on day one by being added to the right groups; a leaver loses them all when one account is disabled; MFA and password policy are enforced in one place; and every login is logged centrally. The risk is concentration: the identity-provider account is now the key to everything, which is why SSO without MFA is worse than no SSO, and why phishing campaigns against finance staff target the identity-provider login page above all others.
Example
# OpenID Connect providers publish their settings at a well-known URL curl https://accounts.google.com/.well-known/openid-configuration # The JSON reply includes authorization_endpoint (the page where you sign in) # and jwks_uri (where apps fetch the public keys that check a login is genuine)
Logging in to the risk dashboard through SSO, step by step, and what the dashboard never sees
- A portfolio manager opens https://risk.example.com. The dashboard has no session for her browser, so it redirects to the firm's identity provider at https://login.microsoftonline.com with a request that says, in effect, please authenticate this user for the application risk-dashboard. With OpenID Connect that request includes client_id, redirect_uri and scope=openid; with SAML it is an AuthnRequest.
- The identity provider shows the login page. She enters her work email and password, and approves the push notification on her phone. The provider checks her password against its own store, confirms the second factor, and notes that her device is enrolled and compliant.
- The provider issues a signed statement: with OpenID Connect an ID token, a JSON Web Token containing sub (her user identifier), email, groups such as risk-dashboard-pm, an issuer, an expiry and a signature; with SAML an XML assertion with the same kind of attributes. The browser is redirected back to https://risk.example.com/callback carrying it.
- The dashboard verifies the signature using the provider's public key, fetched from its published jwks_uri (OpenID Connect) or metadata file (SAML), checks the issuer, the audience and the expiry, then creates its own session for her and shows the portfolios her group may see. Her password was never sent to the dashboard; it has no password column for her at all.
- Twenty minutes later she opens the research portal. It redirects to the same identity provider, which already has a session cookie for her browser and immediately issues a new token without asking her to log in again. That is the single in single sign-on.
- What goes wrong: a phishing email leads a colleague to a lookalike login page that captures his password and relays his push approval. Because he had SSO, the attacker now has every application. The firm's response is to move from push approvals to phishing-resistant passkeys, which cannot be relayed to a lookalike domain, and to shorten token lifetimes so revocation takes effect quickly.
SSO moves authentication to one identity provider that signs a statement about you, which each application verifies with the provider's public key; the applications never see your password, so the provider's login must be the best-protected page in the firm.
Common pitfalls
- Deploying SSO without enforcing MFA at the identity provider: one phished password then opens every application instead of one.
- Leaving local accounts alive beside SSO: an application that still accepts its old username and password has a back door that bypasses every central control.
- Trusting a token without checking the signature, issuer, audience and expiry: an application that skips any of those will accept tokens meant for another application or forged outright.
- Confusing authentication with authorisation: SSO says who you are; which portfolios you may see still depends on groups and roles that someone must maintain.
- Setting token or session lifetimes to days for convenience: a disabled leaver's existing tokens remain valid until they expire, so long lifetimes delay offboarding.
Frequently asked questions
How does single sign-on work?
An application redirects you to an identity provider, which authenticates you once (password plus a second factor) and returns a signed statement of your identity and groups, as a SAML assertion or an OpenID Connect token. The application verifies the signature with the provider's public key and starts a session. Other applications repeat the redirect, but the provider already has your session and signs without asking again.
What is the difference between SAML and OpenID Connect?
Both deliver a signed identity statement from an identity provider to an application. SAML, from 2005, uses XML assertions posted through the browser and dominates older enterprise software. OpenID Connect, from 2014, is a layer on OAuth 2.0 that uses JSON Web Tokens, suits web and mobile applications and APIs, and powers logins such as Sign in with Google or Microsoft. New applications usually choose OpenID Connect.
Is SSO secure?
It is more secure than dozens of separate passwords when the identity provider enforces multi-factor authentication, device checks and central logging, because policy and offboarding happen in one place. It is less secure when it does not, because the single login then unlocks everything. The identity provider's login page becomes the firm's most valuable target, so phishing-resistant factors such as passkeys matter most there.
What is the difference between SSO and a password manager?
A password manager stores a different password for each site and types it for you; each site still checks its own password. SSO removes the per-site password entirely: the site trusts a signed statement from the identity provider and never holds your credential. Password managers are a personal tool; SSO is an organisational architecture with central control over access.