Single Sign-On (SSO) - Simply Explained

You've signed in twice today and never typed a single password. One login is replacing the dozens of accounts you used to juggle, and it's happening in almost every company. You might think single sign on means every app shares your password, but that's not it at all. The apps never see your password. They just trust one service to vouch for you. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Today, we're breaking down single sign on in plain words, and by the end you'll see how it works and where it gets risky. Why one login feels like magic. Think about the last time you started a new job. Within the first week, someone handed you a list of tools to log into. That list included email, chat, the project tracker, the expense system, and the HR portal. Each one wanted its own username, its own password, and its own little rules about how many capital letters and symbols it demanded. So you did what everyone does. You reused a password you could actually remember, or you wrote the passwords down, or you let the browser save them all. Then came the reset emails, the locked accounts, and the ten minutes of your morning spent guessing which version of your password belonged to which tool. None of those choices is foolish, and each one is a small gamble that the wrong person never finds it. Single sign on exists to end that mess, and the idea behind it is simple. You sign in once with one set of credentials, and then you can open every app you are allowed to use without signing in again. The whole idea comes down to one login that reaches many apps, and everything else here builds on that. Now you might be thinking that sounds exactly like the password manager your browser already has, and it works differently. A password manager remembers a different password for every site and types it in for you, but the apps still each hold their own password and check it themselves with single sign on the apps, stop holding passwords entirely and hand that job to one trusted service, which then decides whether you're really you. The app never holds your secret, and it never stores it either. That single shift is why Single Sign On shows up in almost every company now, and it's also why IT teams care about it so much. Fewer passwords floating around means fewer resets, fewer sticky notes, and less time lost every single morning. It also means that when someone leaves a company, an admin can shut off access in one place. Instead of hunting through twenty different tools for the person on the other end that shows up as fewer passwords to remember and far fewer calls to the help desk. The trouble is that the same design, which makes single sign on so smooth, is also the design that makes it dangerous. That's the part we're building toward, and it changes how you see that login screen forever. The two players in every login, every single sign on setup has two main characters, and once you know their names, the whole thing clicks into place. The first is the app you're trying to open, which the industry calls the service provider. You can just think of it as the thing you want to get into. The second is the central login service called the Identity Provider, and that's the system which actually checks who you are. Microsoft Entry ID is one of those identity providers. If you use Microsoft three hundred sixty five at work, entry is where your work account lives, and it's the newer name for what used to be called Azure Active Directory. Other companies rely on identity providers like Okta or Onelogin, but the shape of the idea never changes. One service becomes the place where identity gets checked. The relationship between the two is what makes it all work, and they agree on it ahead of time. They seal that agreement with something like a certificate, which is what lets the app trust a message. When the identity provider confirms that a person is who they claim to be, the app checks the signature. That signature proves the message really came from the trusted source, rather than from someone pretending. The message itself is what we call a token, and a token is a small packet of signed information about you. It usually carries basic facts like your email address or your username. It isn't your password and it doesn't contain your password. It works more like a signed note that says who you are, and in some cases, what doors you're allowed to open. That last part is the piece people get wrong all the time. Single sign on doesn't mean every app shares one password. The app never sees your password at all. Your password only ever goes to the identity provider, and the app just trusts the provider's word. That's the whole trick, and it's a much better deal for everyone involved. A calendar, a chat app, and a payroll system are all service providers. When you reach them this way, what happens when you click sign in? A single login is easier to follow step by step than it sounds, so it's worth tracing one from the beginning. You open an app you haven't touched before, and the app has no idea who you are Instead of asking for a password, it sends you over to the identity provider with one simple request. It wants to know whether this person is signed in and allowed in. Here. The provider checks something. First, it looks at whether this person has already proven who they are recently. If the answer is yes, it skips the whole login screen and sends you right back with a token. That's why some apps open instantly, and it's why signing into one Microsoft three hundred sixty five app can quietly open the door to the others. In practice, that check usually runs against a sign in session that lives in your browser, and the session is the thing that remembers you between apps. Clear that session and the next app will ask you to prove yourself all over again. If you haven't proven yourself yet, the provider asks you to. That usually means your password, and these days it often means a second step as well, like a code from your phone or an approval tap. This second step has a name you've probably heard, which is multi-factor authentication or MFA. It just means you prove who you are in more than one way. Once the identity provider is satisfied, it hands you a signed token and sends you back to the app you started with. The app reads. That token checks the signature against the agreement. It's set up earlier and lets you in. If everything lines up, you never type the password into the app and the app never stored one. Now open a second app. The same dance starts again, except this time the identity provider already knows you, so you skip straight past the login screen. Open a third and the exact same thing happens without you noticing. This is the moment where single sign on earns its name, because you signed in once, and every door after that simply opened. If something about that token doesn't check out the app refuses entry and you're back at the sign in screen, that's not a bug. It's the system working exactly as designed. Because a token that fails the check is a token the app has no reason to trust. An expired token behaves the same way, which is exactly why the app fetches a fresh one. Before that happens. That flow is the heart of the whole system, and it all rests on one small object doing an enormous amount of work. Everything you just saw depends on the token, so it's worth understanding exactly what lives inside one tokens. The signed notes that prove who you are. The signature is what makes the token trustworthy, and it's the detail that does the most work in the whole system. When the app receives a token, it checks that signature against the trust it shares with the identity provider. If someone tried to write their own note claiming to be you, the signature wouldn't match and the app would reject it. That mismatch is the first line of defense. When you sign in with a modern protocol, you usually walk away with more than one token and each one has a different job. The first is the ID token, and its whole purpose is to prove who you are. Microsoft compares it to a nametag at a conference, and that's a fair picture. It carries basic facts about you, like your name or your email, and it's meant for the app to read rather than for calling other services. The second is the access token, and this one is about permission rather than identity. The ID token answers who you are and the access token answers what the app is allowed to fetch. It's the pass and app users when it needs to pull your data from another service, and it's the piece that keeps your access scoped to what you actually agreed to. That's scoping matters. Because an app should only get the slice of access it really needs and nothing more. The third is the refresh token, and its job is to keep you signed in without nagging you. Access tokens and ID tokens are short lived on purpose. An ID token is good for about an hour by default, and when it runs out, the app uses the refresh token to get a fresh one. Behind the scenes refresh tokens last far longer, which is why you don't have to log in again every sixty minutes. There's one more distinction worth holding on to because it trips people up constantly. OAuth two point oh, which you'll see mentioned next to OpenID connect, is not a login system. OAuth is about access, meaning it decides what an app can reach on your behalf. OpenID connect is the layer that handles the actual sign in the who are you question. They work together and confusing the two is behind a great deal of bad documentation. That brings us to the uncomfortable part. All of this trust rides on tokens, which means the most valuable thing a thief can steal isn't always your password. It's a live token. Because a valid token can walk straight past the door. Saml versus OpenID connect two systems can only talk if they share a language, and single sign on has two big ones. The older language is Saml, which stands for Security Assertion Markup Language. It has been the workhorse of corporate login for well over a decade, and it wraps its messages in a bulky format called XML. XML is good at carrying a lot of detail about a user, which is exactly what big companies wanted when they built their systems around it. That detail can include a person's department, their job title, or the groups they belong to. And some apps use those details to decide what to show them. Oidc carries the same kind of information, but it packages it as claims inside a token instead of XML. The newer language is OpenID connect, often shortened to Oidc. It's built on top of OAuth two point zero, and it uses a compact format called Json instead of XML. That makes it lighter and easier for developers to work with, and it fits the way modern apps are built. Web apps, mobile apps, and the single page apps that feel like desktop software all get along with Oidc. Naturally, the trade off comes down to age and fit. Saml is everywhere in older enterprise software, and it's still the standard that many large organizations already run. Oidc is simpler to build with, and it handles mobile and modern app designs far more naturally. If you want a mental picture, Saml is like a formal letter covered in official stamps, while Oidc is like a quick text message that's easier to send and easier to read. You don't need to memorize any of this, and the short version is enough. The two languages exist because two different eras of software needed to solve the same problem, and knowing which one your company uses tells you a lot about how modern its setup is. Microsoft's own guidance is clear if you're the one choosing. Both protocols are secure, and Android supports each one fully. For brand new cloud apps, the default advice is to go with OpenID connect because it fits modern development and the way companies buy software. Today, Samuel tends to show up when an older system only speaks Saml, or when a compliance rule or a procurement contract demands it. That's why you'll sometimes hear two engineers argue about Saml versus Oidc, as if one of them is simply wrong. In practice, the right answer usually depends on what the app already supports and what the customer requires. Plenty of companies end up running both at the same time, which is a perfectly normal place to land. Nobody has to lose the argument for both systems to keep working side by side. So that's the theory behind the two languages. Now it's time to bring this back to the system. Most of you actually log into every morning because that's where it stops being abstract. Microsoft entry. So at work, Microsoft Entry ID is Microsoft's identity provider, and it's the place your work or school account lives when your company uses Microsoft three hundred sixty five entry. Is the system standing behind the login box. It's also the newer name for Azure Active Directory, so if you've heard that older term, it points to the same idea. The piece that makes entry practical is the application gallery. Instead of Hand-building a connection to every tool a company uses, Microsoft keeps a catalog of pre-built connections for thousands of apps, and it can add one in minutes. You can find the gallery under Enterprise Apps in the Enter Admin Center, though as a regular user, you'll mostly just see the result of that work from the user side. That result often shows up in one portal, where every app in your list sits together, ready to open with a click from your site. The experience is almost boring, and that's the point. Your company connects an app. It shows up in your list of available apps, and you open it without retyping a password. You might not even realize single sign on is happening, because the good version of it disappears into the background. Not every app connects the same way, and the difference is worth knowing. Most modern cloud apps connect through Saml or OpenID connect the two languages we just covered. Some older apps only understand a username and a password, so enter offers a fallback where it securely stores those credentials and signs you in on your behalf. There's also a setting called Linked sign on, but that one is really just a bookmark during a migration, and it isn't true single sign on at all. Entra also gives it a way to judge how safe an app is. Each app in the gallery gets a risk score from one to ten, where one is the riskiest and ten is the safest, and that score pulls from more than ninety factors. Those factors range from how the app handles encryption to whether it supports multi-factor authentication. The score isn't a guarantee, but it gives an admin something concrete to look at instead of a gut feeling. Every benefit we just described comes from the same source, and that same source is also the biggest weakness in the entire design. That's where we're headed next. The honest risks. Everything that makes single sign on convenient comes from putting all of your access behind one login, and that's exactly what makes it risky. Security people call this a single point of failure, which is a plain phrase for a real problem. If the identity provider goes down, people can get locked out of every connected app at once. If it gets breached, an intruder can move across systems instead of being stuck at one door. The bigger threat is token theft, and it's worth understanding why it matters. Remember that a stolen token gets an intruder past the door without a password. Attackers know this, so instead of guessing passwords, they go after the tokens themselves through phishing pages, malicious browser extensions, or malware sitting on a machine. In some cases, a stolen token lets a thief skip multifactor authentication entirely because the app sees a signed note and trusts it. There's a subtler risk, too, and it lives in the setup rather than the technology. A connection that's misconfigured can open a gap that's easy to walk through, and an app that someone connected without telling it sits outside all the careful controls. Both problems come from the same place, which is the gap between how a system is supposed to be configured and how it actually ends up. None of this means single sign on is a bad idea. It means the same design hands you both the ease and the exposure, and you can't take one without managing the other. The fixes are well known, and most of them come down to one idea, which is making the front door harder to walk through, require multi-factor authentication, and prefer the stronger phishing resistant kinds where you can watch the sign in logs for odd activity. Keep each person's access limited to what their job actually needs and cut off access the moment someone leaves. Many companies also add rules that only allow a sign in from a managed device or a trusted location, which narrows the openings a thief can use when you put it all together. The strength of a company's single sign on is really the strength of its weakest configured app. One sloppy connection can undo plenty of careful work, and that's the trade you accept when you put every door on one key. Wrapping up with one question, single sign on is a trust relationship, where one identity provider vouches for you. To many apps, the very thing that makes it smooth, that one key for every door is the same thing. That makes it worth protecting. The ease and the exposure are two sides of the same coin. So here's the question I'll leave you with. If one login now opens everything you use at work, how much do you really know about what stands behind it? Subscribe to M365 FM, where we break down the tools and the ideas shaping the future of work. One plain explanation at a time.