OpenID Connect - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. The sign in you never think about. You've used OpenID connect more times this week than you realize, and you never knew its name. It answers one simple question every app has to ask. And that question is who is this person? It sits underneath the Microsoft sign ins you do every morning, and it has been there for years. This is the M365 FM podcast where we explore the people, ideas and technologies shaping the future of work. By the end, you'll see the full sign in flow in plain language, where it shows up in Microsoft three hundred sixty five and Azure and the honest limits people trip over. OpenID connect is a shared set of rules that lets one app trust another app to confirm your identity.

0:40 That's the whole idea, and everything else is detail. When a website shows you a sign in with Microsoft button, it's handing that job over to Microsoft. Instead of asking you to invent one more password. The app never learns your password, and it never needs to because Microsoft vouches for you instead. A standard in this context is simply an agreement that a lot of companies choose to follow. It's the same idea as every phone charger sharing the same plug shape, so you don't need a different cable for every device you own. When everyone agrees on the rules for identity, an app built by one team can trust a sign and handled by another. That trust is what lets the whole thing work at a scale no single company could manage alone. There's a single sentence that makes the rest of this episode easier to follow. OAuth two point oh handles what you're allowed to do, and OpenID connect handles who you are.

1:21 Most of the confusion around identity comes from mixing those two jobs together, so keep them apart and the rest falls into place. You've probably heard the phrase single sign on before, and this is where it comes from. One login can carry you into many apps without a single repeated password prompt. Two names are worth knowing. Before we go any further, the service that checks your identity is called the Identity provider, and the app that trusts that check is called the Relying Party. In the Microsoft world, the identity provider is Microsoft, and the relying party is whatever app you happen to be signing into. Those two roles show up in every conversation about this topic, so they're worth the 10s it takes to learn them. Picture a project tool your team adopted last month. Instead of creating one more login, you click Sign in with Microsoft and you're in. Nobody sends you a confirmation email.

2:03 Nobody asks you to pick a password with a number and a symbol in it, and nobody keeps a copy of your credentials. That small convenience is the surface of a much bigger machine, and the machine is worth understanding. The story of why it exists starts with a different standard that came first. Why OAuth two point oh wasn't enough on its own. Oath two point zero showed up first, and its job was never about identity. It let an app reach into your data without ever holding your password. And it did that with something called an access token. You can think of that token as a permission slip with an expiration date and nothing more. It spells out what the app may do and it says nothing about who you are. That gap turned into a real problem once apps started multiplying. Every company that wanted to know your identity bolted its own version onto OAuth, and those versions rarely agreed with each other.

2:48 Moving between tools meant signing in again and again, and each new app meant another password to remember and eventually forget. People ended up reusing the same weak password everywhere, which is exactly the habit that makes a single breach so damaging. OpenID connect fixed that by adding a second token to the exchange, and this one has a single purpose. The ID token exists to prove your identity. While the access token still carries what you're allowed to do. Splitting those two jobs is what made single sign on work across many apps. An app could finally learn your identity without pretending a permission slip was an identity card. It also settled the parts OAuth had left up to each company. Scopes, which describe what an app is asking for, became consistent across providers. Discovery, which lets an app finder providers addresses on its own, became consistent too.

3:32 When everyone follows the same rules, a developer can move between providers without relearning the basics each time. None of this was a small tidy up before the standard identity was stitched together app by app, and every stitch was a place where something could break. The new layer gave everyone one shared way to ask the same simple question, and that consistency is what made Modern sign in feel effortless. The payoff for you as a user arrives in a single moment, and it's the moment you click sign in. What actually happens when you click sign in? The click takes about a second, but a surprising amount happens inside it. Follow the trip once and the whole standard stops feeling abstract. Your app sends you over to the identity provider with a small marker attached. And that marker is the word OpenID. It's the signal that says this app needs to know who this person is, not only what they can reach.

4:16 Microsoft takes over. From there. You type your password on Microsoft's page rather than the app's page. And if your organization requires a second factor, that check happens here, too. The app never sees any of it. When you're finished, Microsoft sends you back to the app with a short lived code instead of your credentials. The app trades that code for tokens behind the scenes. That's how it ends up with proof of your identity without ever touching your password. Two small values right along to keep the exchange honest. One is a random string called the nonce, and the other is called state. Both act like a receipt number that has to match on the way back. When the numbers don't line up, the app refuses the response because that mismatch is exactly what a replay attack looks like. This design is why a breach at one website can't hand over your Microsoft password.

4:58 The app holds tokens and tokens can be revoked, which is a far better position than a stolen password that opens everything at once. The recommended version of the flow adds one more safeguard, called PXE. it uses a random value the app keeps and then presents later. So a stolen code is useless to anyone else who grabs it. There's one more quiet convenience worth mentioning. The provider publishes a public list of its own addresses, and an app can read that list instead of hard coding anything into its code. That list is why a developer can point an app at Microsoft and let the rest of the plumbing find itself. It's also why switching providers later is less painful than it sounds. If Microsoft rotates its signing keys, which it does on a schedule, the app can pick up the new ones from that same list without anyone editing the code.

5:42 One detail is easy to miss, and it explains a lot of what you see on screen. All of this happens over redirects, which means you briefly leave the app and come back. That little hop is why a sign in sometimes flashes the Microsoft page for a moment. It's also why the app needs a registered return address, so your credentials can't be sent to the wrong place. The proof comes back as a token, so the next step is to open it up and see what's actually inside. What's inside the ID token. The ID token is a small package of facts about you, and its format has a name that sounds harder than it is. It's called a Json web token, usually shortened to JWT and pronounced jot. What you see is a long string of letters and dots, which is why people find it intimidating. The contents are simple and few provider signs the package with a private key.

6:22 Any app can check that signature with the matching public key before trusting a single word of it. Inside, you'll find a handful of standard entries, and each one answers a basic question. One entry names the issuer, which is the provider that created the token in the first place. Another entry, called sub, is a unique identifier for you, and it deliberately isn't your email address or your name. Another name is the audience, which is the app. The token was made for a token meant for one app. Can't be quietly reused by a different one. That last entry is a small detail with a big job. It stops a valid token from being used somewhere it was never meant to go. The rest are about time and context. One entry says when the token expires, one says when it was issued and one says when you actually signed in, the nonce from earlier shows up here as well. It's how the app confirms that this token belongs to the sign in it started and not some other one.

7:06 An app that checks all of these is doing real work from your side of the screen. It looks like nothing happened at all. Signing is what turns this from a note into proof. Without a signature, an ID token would be a piece of paper anyone could write. The app would have no way to tell a real one from a forgery. The honest part is that the app has to check it anyway. A token that arrives and gets trusted without that check is nothing more than a confident looking string. That mistake shows up in real systems far more often than you'd expect. It's one of the reasons security teams get nervous about homegrown sign in code. There's a limit worth naming here because it keeps expectations honest. An ID token tells an app who you are. It has no opinion about whether you should see a particular record or click a particular button. The app still has to make those decisions on its own, using the identity it was handed as the starting point.

7:50 This is where the Microsoft tools you already open every day come into the picture where this shows up in Microsoft three. Sixty five and Azure. Microsoft's identity service is called Microsoft Entry ID, and most people still know it by its old name, Azure Active Directory. Microsoft announced that Rename on July eleven, twenty twenty three, and the name changed while the underlying behavior stayed the same. If your sign in worked before that date, it worked the same way afterward. That's why the old name still floats around in older articles and job postings. The service behind entry ID speaks OpenID connect, and that's the connection worth holding on to. It means the same machinery powers a sign in with Microsoft button on some random website. That same machinery signs you into teams SharePoint and OneDrive.

8:32 You sign in once in the morning, and every one of those tools accepts that single sign in for the rest of the day. From where you sit, it feels like the apps already know you, and underneath that feeling is the standard doing its quiet work. That's single sign on. And it works because the provider can reuse a session it already trusts. Your organization also gets a private slice of the system called a tenant, and it decides who is allowed through the front door. An app can be pointed at just your organization, at any organization, or at personal Microsoft accounts, depending on who it was built for. That single setting is why a work app can keep outsiders out. While a consumer app can welcome anyone with a Microsoft account, this reaches further than sign in pages, and beginners rarely hear about it. If you build a Power Pages site, you can plug in OpenID, connect with entry ID and let visitors use their work login.

9:17 Custom connectors work the same way, so an app you build can trust your organization's identity without you writing any identity code yourself. For a maker who has never touched authentication, that's a real shortcut. The hardest part of building an app is often the part that proves who people are. None of this requires you to be a developer, and none of it asks you to manage anything. It's already running, and the most useful thing you can do is recognize it. Once you can name the thing the next time a sign in behave strangely, you'll at least know which layer to look at. One honest note before we move on. OpenID connect is one layer inside a Microsoft sign in, and plenty of other pieces sit around it, including multifactor prompts, device rules, and licensing. This standard handles identity and it doesn't handle all of that, so treat it as one important part rather than the whole machine.

9:59 Because this is everywhere. The mistakes are everywhere too. The mistakes people make and the honest limits. The first mistake is treating the ID token as a key. It proves who you are and it grants you nothing. So an app that leans on it for permission has confused the two tokens. The access token opens doors, while the ID token is the one that says your name. Mixing them up feels harmless in a quick demo and turns into a real hole once the app faces the internet. The second mistake is accepting an ID token without checking it. That's like letting someone into a building because they handed you a note that says they work there. The signature and the standard entries are all checkable, and skipping that step turns a strong guarantee into a hopeful guess. Many apps receive a token and wave it through because the library made the whole thing look automatic. The check was quietly missing the entire time.

10:41 The third mistake is using OpenID connect, where no person is involved. When two servers need to talk to each other with no human present, OpenID connect is the wrong tool. The right one is the OAuth client. Credentials flow. It's a common mix up because the two protocols look almost identical on the surface. The difference only shows up when you ask who is being signed in. If the honest answer is nobody, then you're reaching for the wrong standard. The fourth mistake is reaching for an older flow that the modern world has moved past. The implicit flow exists mainly for cases that can't use the recommended path. That path is the authorization code flow with a security add on called Pkcs. A tutorial that still teaches the old way is usually a sign that it's out of date. Following it can leave an app weaker than it needs to be.

11:23 Then there are the honest limits and they matter more than the mistakes. OpenID connect doesn't decide what you can do once you're inside, and it doesn't tell anyone how you should prove your identity. It carries an identity between systems and the rules that govern access. Live somewhere else entirely. Expecting this standard to handle permissions is a little like expecting a passport to open every door in the country. It's also not magic because it's an agreement, and an agreement only holds when both sides follow it. A provider that signs carelessly or an app that checks nothing can turn a good standard into a weak door. No protocol can repair that from the inside, which is why the details matter more than the name. The standard hands you a strong foundation, and the building still depends on how carefully each side builds on top of it. Once you see those limits, it gets easier to understand why the standard won out over the older way of doing the same job, how it stacks up against the older way.

12:09 The older way is Saml and it chases the same goal with a very different toolkit. It also outsources sign in to a trusted provider, and it also lets one login carry you across many apps. The difference is the packaging. Saml is written in XML which is heavier to work with. It was built mainly for web pages in an era before phones and apps took over the world. OpenID connect is lighter and built on Json, a format that's easier for modern software to read and write. That's why it works just as well in a mobile app or a desktop tool as it does in a browser. It also hands back an access token alongside the identity proof. So one exchange covers both your identity and what you can reach. Saml was never built for that second job. That's part of why it started to feel like a square peg. Once APIs became the center of everything.

12:51 Saml isn't gone, and plenty of large organizations still run it for older systems. OpenID connect is the newer default, and it's the one you're most likely to meet in anything built this decade. Knowing both names helps because you'll run into each of them depending on where you work. If you move between companies, you might find one running Saml on the inside and OpenID connect at the edges, and that mix is completely normal. The practical point is simple when you see Saml, you're looking at the past holding on, and when you see OpenID connect, you're looking at the default for what comes next. So let's bring this back to your own day and what it actually means. What this means for your own work. You don't have to build any of this to benefit from it. And that's the most freeing part of the whole story. OpenID connect is already running underneath the sign ins you use every morning, and now you can recognize it while it's working.

13:32 When a sign in feels completely invisible, that's usually the sign that it's doing its job well. The whole point is to get out of your way. The short version is worth sharing with you one question, which is who are you? And one token the ID token that answers it. One flow carries that answer between systems and one place it lives in your world, which is Microsoft Entra ID. If you remember nothing else, remember that the standard is a way of answering one simple question safely. It does that over and over between systems that don't know each other yet. That matters more than it sounds, because we hand our identity to software dozens of times a day without a second thought. Once you can see the machinery, you start to notice where it's solid and where it's thin. That awareness is where real understanding begins. You don't need to become an identity expert to ask a better question.

14:12 The next time something about a sign in feels off, here's a question to sit with after this. Where in your own work have you been trusting a sign in? You never really understood if this made the topic feel less intimidating. Subscribe to M365 FM to master the tools and the mindset shaping the future of work.