What Is SSO?
SSO, single sign-on, means a single login opens every system the user has rights to. Instead of separate accounts in each tool, a central identity service authenticates the person once, and the other systems trust that confirmation. That gives users fewer passwords and gives IT one place to cut off access.
SSO stands for single sign-on and means a single login grants access to every system a person is entitled to use. Instead of a separate username and password for email, the business system, time tracking, and the intranet, the user logs in once – and the rest opens automatically. Behind the scenes, it’s handled by a central identity service that every system trusts.
The analogy: the hotel key card
Think of a hotel. You check in once at reception and get a key card. That same card then opens your room, the gym, the pool, and the parking garage – without you identifying yourself again at every door. The doors don’t check who you are; they ask the hotel’s system whether the card is valid right now.
SSO works the same way. You “check in” by logging in to the identity service, and every system you open asks that same service whether you are who you claim to be. So the systems don’t store your password – they rely on the confirmation from the central service. And just as reception can block a lost card immediately, IT can shut off a person’s access to everything in one place.
The double benefit: simpler for users, safer for IT
SSO solves two problems at once, which is why the technology has become standard in most organizations.
- Fewer passwords for the user. One login instead of ten means fewer forgotten passwords, fewer resets, and less temptation to reuse the same password everywhere. Everyday life gets simpler and support tickets fewer.
- Central deactivation for IT. When an employee leaves, it’s enough to deactivate the person in one place, and access to every connected system shuts off at the same moment. This is perhaps the most important security win: forgotten, active accounts in old systems are a classic way in for intruders, and that route disappears.
On top of that comes a third benefit that often becomes clear only in hindsight: overview. IT gets a unified picture of who has access to what, instead of chasing down accounts system by system.
How it fits together technically
At the center sits an identity service – often called an IdP, identity provider – like Entra ID, Okta, or Google Workspace. It’s the one that verifies the user. Every connected system links to the identity service through a standard, in practice SAML or OpenID Connect, the requirement terms you’ll run into in proposals and requirement lists.
The standard is the actual “language” the systems and the identity service speak to exchange the message this person is logged in and is who they say they are. A system “supporting SSO” concretely means it speaks at least one of these standards. Modern business systems and SaaS tools almost always do by default; older systems may need a middle layer.
A concrete scenario
A company with 120 employees had seven key systems, each with its own password. Support got recurring tickets about forgotten passwords, and whenever someone left, no one knew for sure which systems the former employee still had an account in.
After the systems were connected to a shared identity service, staff log in once each morning. A new employee gets the right access by being added in one place, and someone who leaves is deactivated just as easily. Password tickets to support dropped sharply, and the question “who actually has access to this?” finally got an answer people could trust.
When SSO is worth prioritizing
The more systems and the more employees, the greater the payoff. A small organization with two tools gets by without it; a growing business with a mounting patchwork of systems quickly reaches a point where scattered logins become both a security risk and a daily irritation.
SSO is often introduced as part of a broader effort on integrations between systems – when the tools need to talk to each other anyway, a shared identity is a natural foundation. Thinking about tying together your systems and your login? Get in touch and we’ll sort out what’s needed in your particular environment.
Frequently asked questions
Is SSO the same thing as a password manager?
No. A password manager fills in different passwords for you, but each system still has its own account and password underneath. With SSO, there's no separate password in the connected systems at all – they ask the identity service who you are. That's a fundamental difference, not just a more convenient interface.
Isn't it dangerous to gather everything behind one login?
The combined login obviously becomes important to protect, which is why SSO is almost always paired with two-factor authentication. In return, the overall risk decreases: fewer reused passwords, no forgotten accounts left in old systems, and a single place to shut off access after a breach or a termination.
What's needed to introduce SSO in an organization?
A central identity service, for example Entra ID or Okta, and each system to be connected supporting a standard like SAML or OpenID Connect. Most modern business systems do. Rolling it out is mostly about connecting the systems to the identity service and setting the rules for who gets what.
Does SSO also work for custom-built systems?
Yes. A custom-built system can be connected to the same identity service by building in support for OpenID Connect or SAML in its login. That way the internal tool falls under the same rules and deactivations as everything else, instead of becoming its own password silo on the side.
What happens if the identity service goes down?
Then users can't log in to the connected systems, much like a master key that stops working. That's why a reliable identity service with high availability is chosen. The trade-off is usually worth it: the alternative, scattered logins across every system, produces more failures over time, just less visible ones.