What is single sign-on?

You have almost certainly used single sign-on without knowing its name. Every time you clicked a button that said "continue with" an account you already had, instead of creating yet another username and password, that was SSO doing its job. The idea is simple enough to state in one line: prove who you are once, to a system that other apps trust, and then those apps let you in without asking you to prove it again. The rest of this post explains what is happening behind that button, in plain terms, with no assumed background.

I care about getting this right because the tools I build offer SSO, and I would rather people understand it than take it on faith. But this is a general explainer first. By the end you should be able to picture the moving parts and judge for yourself when SSO helps and when it does not.

The problem SSO solves

Think about how many accounts you have. Email, a few work tools, a bank, a handful of shopping sites, a streaming service or two. Each one traditionally asked you to invent a password. Nobody can remember dozens of strong, unique passwords, so people cope in predictable ways. They reuse the same password across sites, or they pick weak ones that are easy to recall, or they write them somewhere. Every one of those coping strategies is a security problem. A password reused on a small forum that gets breached can become the key to something far more important.

SSO removes the source of the problem. If you only have to authenticate against one trusted system, you only need one strong login, and everything else rides on that. Fewer passwords means fewer weak ones, fewer reused ones, and fewer chances for a leak somewhere small to matter somewhere large.

How it actually works

There are three players in every SSO login. There is you, the person trying to get in. There is the application you want to use, sometimes called the service provider. And there is the identity provider, the trusted system that already knows who you are. The identity provider is the heart of the whole arrangement.

When you try to open an app that uses SSO, the app does not ask you for a password. Instead it sends you over to the identity provider and says, in effect, "I do not know this person, can you vouch for them." You log in to the identity provider, once, the way you normally would. The identity provider checks you, and if you pass, it hands back a signed token. A token is a small, tamper-evident message that says "this is Farhan, and I, the identity provider, confirm it." Your browser carries that token back to the app. The app checks the signature, sees that a system it trusts vouched for you, and lets you in. You never gave the app your password, because the app never needed it.

The token is the clever part. It is signed in a way the app can verify but nobody can forge, so the app can trust it without phoning the identity provider for a second opinion on every click. That signature is what lets many different apps rely on one login safely. There are two main technical standards for producing and carrying these tokens, and if you ever want the deeper version, I compare them in a separate piece, but you do not need that detail to understand the concept here.

The benefits, from a user's side

The most immediate benefit is that you stop drowning in passwords. One login gets you into everything, so there is less to remember and less to get wrong. That convenience is real, but it is not the most important part.

The bigger benefit is quieter. Because one system handles your identity, that one system can be protected properly. It can require a second factor, notice a login from a strange place, and enforce good habits that individual apps would never bother with. You get the security of a well-guarded front door instead of dozens of flimsy side doors, each secured differently or not at all.

For anyone managing more than themselves, there is a third benefit: control. Access can be granted and removed in one place. That is why organizations lean on SSO so heavily, a subject I cover from the buyer's angle in what enterprise SSO is and why buyers ask for it. For an individual, though, the first two benefits are the ones you feel every day.

A quick walk through one login

It can help to slow the whole thing down and watch it happen once. Say you open a project tool for the first time on a Monday morning. The tool notices you are not signed in, and rather than showing a password box, it bounces your browser to your identity provider. You recognize that screen, because it is the same one you use for everything else at work or the same personal account you already trust. You log in there, perhaps approving a prompt on your phone as a second step. The identity provider is now satisfied that you are you.

At that point the identity provider builds the signed token and sends your browser back to the project tool with it attached. The tool reads the token, checks the signature against the identity provider it trusts, and sees a valid statement of who you are. It creates your session and shows you your work. From your side it felt like one quick redirect. Underneath, an entire verification and vouching handshake happened in under a second. The next tool you open that trusts the same provider may not even ask again, because you are already signed in to the provider, which is where the "single" in single sign-on comes from.

The honest trade-off

SSO is not free of risk, and pretending otherwise would be the wrong way to explain it. When you put one login in charge of everything, that login becomes the single point everyone has to protect. If someone breaks into your identity provider account, they do not get into one app, they get into all of them at once. You have concentrated the value, which means you have also concentrated the target.

This is not a reason to avoid SSO. It is a reason to protect the central login well, which turns out to be far easier than protecting dozens of scattered ones. The standard answer is to pair SSO with multi-factor authentication, so that getting into the identity provider requires more than a stolen password. I explain that companion piece in what multi-factor authentication is, and the two are meant to be used together. SSO decides who holds the keys. MFA makes sure the keyholder is really you.

Where you will meet SSO

You meet SSO in two flavors. The consumer flavor is the "continue with" button that uses a big personal account to sign you in to smaller apps. The work flavor connects a company's own identity system to the tools its employees use, so the company controls access from one console. They share the same mechanics, a trusted identity provider handing signed tokens to apps, but the ownership is different. In the consumer case a large provider owns your identity. In the work case your employer does.

The products I build sit in that second world. Atlas, the wrxstack work platform, offers SSO so a team can connect it to the identity provider they already use, and it keeps an audit log of activity inside the product. I want to be precise about the boundary, because honesty is the point of this whole site. wrxstack is an AI work platform, not an identity company. It relies on your identity provider for the login itself and does not try to replace it, and it does not offer automated user provisioning or a named role framework. You can read exactly what is and is not in place on the security page, and see how SSO fits the product on the Atlas page.