OAuth 2.0 - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Why apps never ask for your password anymore. Your password is the master key to your account, and OAuth two point oh is the valid key. It's the reason you can sign into a brand new app with your Microsoft account and never hand over your password. You've used it without noticing every time a site offered to sign you in with Microsoft or Google, the whole thing is a handshake between four players, and you're the most important one. There's one detail in that handshake. Most people get wrong, and it's the same detail that opens real security holes. OAuth stands for open Authorization, and it's the standard that lets one app reach your data inside another app without ever holding your password. That last part is the point before the standard existed.

0:40 If you wanted a new app to work with your calendar or your files, you handed that app your username and password, and then you simply trusted it to behave. It could read everything, change everything, and it kept your password forever. OAuth was built to end that arrangement. It replaced an earlier version called OAuth one point zero back in twenty twelve, and it has become the standard way apps get permission online when a site offers to let you sign in with Microsoft or Google. When a scheduling tool asks to see your calendar. When a little widget wants your location, you're watching OAuth do its job. If you've ever felt lost in a conversation full of acronyms, this is one worth having in your pocket. OAuth isn't a product you buy or a setting you switch on, and it's the quiet agreement sitting underneath the tools you use every day.

1:22 That's why it turns up in personal projects and inside big companies alike. The idea clicks once you see it. Instead of your password, the app gets a limited temporary pass that you agree to. It's the difference between handing a valet the key to your car and handing a stranger the keys to your house. The valet can move the car and nothing else. One thing matters more than the rest. Before we go further, you might think OAuth is about signing you in, and it's actually about granting access, not proving identity. It's very good at saying that this app may read this one thing for a little while, and it was never built to check your identity. People confuse those two jobs constantly, and that confusion is where the real mistakes live. The four players in every OAuth handshake, every OAuth sign in involves four characters and each one has a job.

2:03 Meet them in the order they matter to you. The one that matters most is you, because the data belongs to you and only you can say who gets to touch it. In the formal language, you're the resource owner, which just means the person who owns the data. When you tap approve on a permission screen, you're doing something no app can do for itself. The app you're trying to use comes next, and the protocol calls it the client. It's the newcomer in the room, and it wants something specific. Maybe it wants to read your calendar so it can schedule a meeting, and it can't get that on its own. Then there's the login server known as the authorization server. This is the trusted middleman, the one that shows you the permission screen, checks who you are and decides whether to hand out a pass. In Microsoft's world, this is the sign in page you've seen a thousand times, and will put a proper name on it in a few minutes.

2:44 Finally, there's the place your data actually lives, called the resource server. This is the destination. The mailbox, the file storage, the calendar. When the app reads your data at the end, it's talking to this one. One more detail about the login server because it explains a lot of what comes next. It has two doors. One door is for you where you sign in and approve the request. The other door is automated and out of sight, and the app uses it to pick up its pass. Once you've approved, keeping those two doors separate is exactly what lets the app get access without ever seeing your password. The names sound formal, and the drops are simple. Once you picture a front desk, you own the room. The app is the guest, the login server is the receptionist checking badges, and the resource server is the room itself, holding everything you came for. Of those four players, the login server is the one beginners tend to forget and it's the one doing the most work behind the scenes.

3:30 What happens when you click sign in with Microsoft? So here's what actually happens. Step by step in the order it unfolds. This sequence has a name, the authorization code flow, and it's the one you'll meet most often in the wild. You start by clicking the button that says Sign In with Microsoft. The app doesn't log you in itself. Instead, it sends your browser over to the login server, along with a note about what it wants and where to send you back afterward. That second part matters later, so keep it in mind the login server takes over. From there. It shows you the permission screen, the one that lists what the app is asking for. It's asking for something specific, like reading your basic profile or seeing your calendar, and you read it and decide whether you're comfortable. If you approve, you've done your part. Now the clever part happens. The login server doesn't hand the app your password, and it doesn't even hand over the real pass yet.

4:11 It sends your browser back to the app with a short single use code. More like a claim ticket than a key. The app takes that ticket and quietly, on its own, secure server trades it in for the actual pass, which is called an access token. That two step hand-off is the trick. The sensitive exchange happens behind the scenes between the apps server and the login server, and not in your browser, where someone could be watching. The ticket is single use as well, so if it were somehow stolen along the way, it would already be spent by the time anyone tried to use it. A stolen ticket is a nuisance and a stolen password is a disaster. There's a newer safety feature worth knowing about, usually called PKI, which stands for Proof Key for Code Exchange. In plain terms, when the app starts the sign in, it invents a one time secret and remembers it.

4:54 When the app later trades in that ticket, it has to show the secret, which proves it's the same app that began the sign in that stops an attacker who grabs the code and tries to cash it in themselves. Picture it with a calendar app, you click to connect your work calendar. Microsoft shows you a screen that says, this app wants to read your calendar and you approve. The app now sees your meetings without ever seeing your password or the rest of your mail. So the sequence is short. You click, you approve, a ticket comes back, and the app swaps the ticket for a token. Your password never moves. That's one flow and it's the common one, but it isn't the only one. Why? There isn't just one OAuth flow. By now, you might be wondering why the same standard looks so different depending on the app. The answer is that a flow is just the set of steps an app follows to get access, and different apps really do need different steps.

5:36 The default and the one we just walked through is the authorization code flow. Usually with that Pkcs safety feature added on, you use it whenever a real person is signing in, which covers most web apps, most mobile apps, and anything with a sign in screen. Now picture the case with no person at all. Picture two services talking to each other at three in the morning with nobody around to click anything. That's the client credentials flow. The app proves itself using its own ID and a secret, and gets a token without any user involved. There's no permission screen because there's no human to ask. The device flow handles gadgets that can't type. Think of a smart TV or a command line tool. The device shows you a short code and a web address. You open that address on your phone, you enter the code and approve it, and the TV gets its access while your password stays on the phone where it belongs.

6:21 One more piece isn't really a flow at all, and that's the refresh token. It lets an app pick up a fresh pass later without dragging you back to a sign in screen every hour, and will cover it properly in a moment. There are also two older flows you should know by name, mainly so you can recognize them as legacy. The implicit flow returned the pass directly through the browser, which made it easy to leak, so it's now deprecated. The password grant asked you to type your password straight into the app, which defeats the entire point of the standard so it's deprecated to the current guidance is blunt about both. Don't use them in anything new. The useful habit is to stop memorizing flow names and instead ask one simple question about any app you use. It comes down to whether a person is signing in or a machine is talking to a machine, and whether the device can even type. The answer tells you which flow is running behind the scenes.

7:03 One standard, then covers a person signing in a server, talking to a server and a television in your living room. The idea underneath is the same and the steps change to fit the situation. The two tokens and the scope that keeps them honest. Every flow. We just covered ends the same way with the app holding a token, so it's worth slowing down to see what a token actually is. The access token is the pass itself. It's a piece of data that says the app is allowed to do a specific thing on your behalf, and it's usually built to expire after a short time. When the app wants your calendar, it shows the token to the resource server and the server checks it and hands over only what's allowed. If the token is missing or expired, the request goes nowhere. That one detail the fact that the pass expires, does more hidden security work than almost anything else in the standard.

7:47 Because access tokens expire, apps need a way to keep working without interrupting you every few minutes. That's the refresh token. It's a longer lived credential that the app stores carefully and trades for new access tokens as the old ones run out. If the access token is a day pass, the refresh token is the membership card that gets you a new day pass. And that's exactly why it has to be guarded so closely. Then there's the piece that keeps everything honest. The scope. A scope is a label that spells out exactly what the app may do. Reading your calendar is one scope, and sending mail as you is a different one. That's why a scheduling app asks to see your calendar and not your inbox. It isn't being polite, and it's asking for a specific scope. So if it asked for more, the permission screen would show you more. Put that next to a password and the difference becomes obvious.

8:28 A password is your whole account forever and it can't be narrowed down. A token is limited to what you approved. It expires on its own, and you can often revoke it without changing your password. You've seen scopes without ever knowing the word. Every time a permission screen says an app wants to read your files or send email on your behalf, it's listing scopes in plain language so you can decide. The honest catch is that tokens can still be stolen when an app handles them carelessly, which is exactly why the next part of the story matters. Where OAuth lives inside Microsoft three hundred sixty five and Azure. This is where the theory lands in the tools you work with every day. If you work anywhere near Microsoft three hundred sixty five, you've been relying on OAuth for years, often without ever saying the word out loud, and the permission screens you click through are the visible edge of all of it.

9:11 Start with the login server because it has a name. Microsoft's version is called Microsoft Entry ID, which most people still know by its old name, Azure Active Directory. Microsoft announced the rename on July eleven, twenty twenty three, and both names point to the same service, so don't let the change trip you up. Next, think about where your Microsoft three hundred sixty five data lives, your teams messages, your SharePoint sites, your OneDrive files, and your outlook mail can all be reached through a single doorway called Microsoft Graph. Every time an app reads or writes something behind that doorway on your behalf, it's carrying an OAuth access token. That token is the reason an app can touch your files without ever knowing your password. Before any app gets that far, though, it has to be registered with the Microsoft Identity platform, and it has to be granted permissions.

9:52 This is the part that shows up in your daily life as the permission screen, and Microsoft splits those permissions into two flavors that explain almost every confusing thing you've ever seen. The first flavor is called Delegated Permission. Here, the app acts as you. and it can only reach what you can already reach and nothing more because it's borrowing your identity for a moment. If you can't see a file, neither can the app. This is the safer of the two, and it's the one Microsoft recommends whenever it's enough. The second flavor is called Application Permission. Here, the app acts on its own with no signed in user at all, which makes it powerful because it can reach anything its permission covers across the whole organization. That's also why only an administrator can approve these. A regular user can approve an app for their own data and application permissions.

10:33 Need someone with admin rights over the entire tenant? You can spot both flavors in the way apps ask. When a small app asks you personally to approve reading your profile, that's delegated when your IT team rolls out a tool that reads every mailbox in the company that's application permission and an admin signed off on it. There's a practical reason this matters to you. Even if you never write a line of code when a permission screen appears in Teams or Outlook, you're the resource owner from earlier, and you're the one deciding how much of your own data and app gets to borrow. Microsoft's own guidance keeps coming back to one rule called least privilege. Give the app the smallest permission that does the job. If an app only needs to read your profile, it should ask to read and not to read and write. Reading and writing is a bigger ask, and there's no reason to grant it when the smaller one is enough.

11:17 The mistakes and the limits worth knowing. Now for the honest part. Because OAuth is safe when it's built well and shaky when it isn't. This is also where that one detail from the start of the episode finally shows up. The most common mistake, and the one detail I told you to watch for, is treating OAuth as a login system. It grants access and it doesn't prove who you are. Those two jobs sound similar, and they're actually different, which is why a companion standard called OpenID connect sits on top of OAuth to handle identity. When a developer skips that layer, they can end up trusting a token that was never meant to prove anything at all. The second mistake is sloppy redirect handling. Think back to the note the app sent at the start, the one telling it where to send you back. That address is called the redirect, and if it's checked loosely, an attacker can swap in their own address and catch the code meant for the real app.

12:02 The current best practice is exact matching, so only the precise pre-approved address is ever accepted. The third mistake is skipping peaks on apps that can't keep a secret. Mobile apps and apps that run entirely inside your browser can't safely store a hidden password, which makes them prime targets. Pkcs was invented for exactly this situation, and there's no good reason to leave it out. The fourth mistake is simply old habits. The implicit flow and the password grant are still out there in older software, even though the current security guidance published as RFC nine thousand seven hundred in January twenty twenty five, tells developers to stop using them and to rely on the authorization code flow with Pkcs instead. There are real limits beyond the mistakes. Two tokens expire, and while that's a safety feature, it means apps have to handle renewal carefully.

12:43 Revoking access isn't always instant everywhere it was granted because the standard is flexible, two implementations can behave differently, which is why the same button can feel smooth on one side and clunky on another. None of this means OAuth is fragile. It means the safety comes from following the rules, and the rules aren't complicated. Use the modern flow, add pkcs, match the redirect exactly and never treat a token as proof of identity. The direction of travel is a tidied up version called OAuth two point one, which folds these best practices in. So the safe path is also the default path for you. The practical takeaway is small. When you see a permission screen, read it because it's showing you exactly which scope an app is asking for. What to take away. And one question for you. Here's where we've landed.

13:24 OAuth two point oh is the standard that lets an app borrow a limited temporary slice of your access instead of holding your password? It works as a handshake between four players you, the app, the login server, and the place your data lives, and it ends with a scoped token that expires. In Microsoft's world. That handshake runs through Microsoft Entra ID, and it's how apps reach your teams SharePoint, OneDrive, and outlook data through Microsoft Graph. None of it is magic, and all of it is something you can now describe to a coworker in one breath. Which brings me to my question for you. When did you last actually read the permissions and app asked for before you clicked accept? Tell me in the comments because I'm genuinely curious how many of us slow down for that screen if this made the topic feel less intimidating. Subscribe to M365 FM.

14:04 To master the tools and the mindset shaping the future of work.