Single sign-on (SSO) in plain English
Remember the wristband at a music festival? You show your ticket once at the entrance. After that, you wear a wristband, and every stage lets you in without further checks – as long as your wristband is valid for it. Single sign-on works on the same principle.
In the morning, you sign in once to a central sign-in service known as the identity provider. After that, email, file storage, HR software, and many cloud services open without you having to sign in again. One widely used identity provider, for example, is Microsoft Entra ID.
But the comparison also shows the downside: anyone who forges or steals a wristband gets in everywhere, too.
How single sign-on works
Technically, an SSO sign-in usually goes like this:
- Opening the application: You open, say, a cloud application. It doesn’t know you yet and redirects you to the identity provider.
- Signing in: There, you prove your identity – ideally with a password and a second factor, in other words with multi-factor authentication.
- Digital pass: The identity provider issues a digitally signed confirmation known as a token. It states who you are and which permissions you have.
- Access: The application checks the signature and lets you in. Your browser remembers the session with the identity provider. That’s why other applications receive their token without you having to sign in again.
There are standards for exchanging tokens. The most common are SAML and OpenID Connect, which builds on the OAuth 2.0 authorization protocol. In classic Windows networks, Active Directory provides a similar one-time sign-in using the Kerberos protocol.
A practical example
A tax advisory firm has connected all its cloud applications to a central identity provider and introduced MFA with app-based approval. An employee receives a very convincing email with a link to what appears to be the sign-in page. The page is a phishing proxy: it forwards every entry to the real sign-in page in real time. The employee enters her password and approves the MFA prompt.
In the process, the attacker intercepts the session token – the digital pass that keeps the sign-in valid for a while. With it, he reaches all connected services – email, document storage, and accounting software – without a password and without a second factor. The attack is uncovered because the sign-in logs show access from an unusual country.
The firm revokes all sessions, resets the password, and from then on allows access only from managed devices. It also switches to phishing-resistant FIDO2 security keys: small USB or NFC keys that only work with the genuine sign-in page.
Why does this matter for businesses?
SSO concentrates sign-in in one place. That has advantages: employees need fewer passwords, safeguards such as MFA apply centrally, and when someone leaves the company, disabling a single account is enough. At the same time, the identity provider becomes the master key to the entire company.
Typical risks include stolen session tokens, too many administrator accounts, applications with faulty token validation, and local accounts that can be used to bypass SSO. Especially critical: anyone who steals the identity provider’s signing key can issue valid tokens for any account themselves – with SAML, this is known as “Golden SAML.” And if the identity provider goes down, nobody can sign in to the connected applications anymore.
How to protect your organization
- Strong sign-in: Enforce MFA for all accounts, ideally with phishing-resistant methods such as FIDO2 or passkeys.
- Access rules: Conditional access policies allow sign-ins only from managed devices or from specific countries, for example.
- Protect administrators: Keep the number of administrator accounts small and use separate accounts for administration.
- No back doors: Disable local sign-ins in the applications once SSO is set up – except for documented emergency access accounts.
- Review connections: Regularly check which applications are connected and which permissions they have.
- Monitor sign-ins: Analyze the sign-in logs and set up alerts for anything unusual.
- Set up emergency access: A specially secured emergency account (often called a break-glass account) keeps you able to act if central sign-in is disrupted or administrators accidentally lock themselves out.
How Rootsektor can help
In our Microsoft 365 & Azure Review, we examine the configuration of Entra ID, Microsoft’s identity service – from MFA and conditional access to administrator roles and connected apps with overly broad permissions. For on-premises Windows environments, our Active Directory Assessment uncovers weaknesses in Kerberos and permissions. Whether your own applications validate SSO tokens correctly is something we test in a web application penetration test.