Modern Auth in M365 is a Maze—Here’s the Map

Tere’s something that catches everyone off guard: your Conditional Access policy might be perfect—but there’s a secret relay between MSAL and token refresh that quietly overrides it. In this episode, I’ll show you the unseen handshake that actually controls Modern Authentication in M365—and what it means for business-critical workflows.The Hidden Workings of Sign-In: Azure AD’s Trust MachineIt’s easy to assume that logging into M365 is nothing more than submitting your password and waiting for the green light. I think we’ve all watched users fly through the sign-in screen and move on with their day. But underneath that smooth experience, Azure Active Directory is running a far more complicated background check. Think of it less as a simple security stop and more like walking up to a security desk after landing at an airport: credentials in hand, but the guard’s not just glancing at your name. They’re quietly checking a whole list of things before they let you head to baggage claim. Picture this: someone opens their laptop in a hotel room, fires up the Wi-Fi, and tries to reach their organization’s SharePoint. You’d expect the system to at least blink at a new location. But sometimes, to everyone’s confusion, the login just works. No extra prompts. No notifications to the admin. On the surface, it looks like the password got them through. But in reality, something more layered is happening within Azure AD’s engine.Behind the scenes, Azure AD acts like a security guard who doesn’t just check your ID, but also notices where you’re coming from, what device you’re using, how healthy that device is, and whether you’re sticking to the organization’s latest rules. That checklist goes way beyond “username and password.” Is the device enrolled in Intune? Is it up-to-date and compliant with company policies? Is the sign-in happening from a familiar location or halfway across the world from yesterday’s login? All those little details—what Microsoft calls “signals”—get swept into the guard’s calculation.Conditional Access is operating as a live rulebook. It’s not just a set-it-and-forget-it wall. Each policy is another instruction for the security guard: sometimes, require multi-factor authentication; sometimes, allow access but only if the device is marked compliant; other times, block the attempt completely if it comes from an unknown country. The more layers you add, the more nuanced the engine becomes. Yet, it also opens up new combinations you might not expect.Let’s take a real scenario. An admin sets a Conditional Access policy to demand MFA whenever someone signs in from outside approved office locations. That’s supposed to catch the user sitting in the hotel, right? But when testing, the admin sees the user hop online and get into SharePoint with nothing but their usual password. Confusing, but not uncommon. Why does this happen? Sometimes, the signals intersect in ways that defeat your expectations. The device might already be marked compliant. Maybe the user signed into another cloud resource earlier in the day, still has a valid session, and rides in on that existing trust. Or perhaps, a previous risk check gave them a window of safe access, so the engine is temporarily relaxing the rules for that user.The more you look at Conditional Access, the more you see that it’s not one rule on its own but a big web of signals and decisions, all happening in real time. User risk, device risk, network location, compliance status—every one of those gets scored the instant someone types their credentials. If any of them tip the scales, the user might get extra hurdles, or they might just slide through. The criteria for “trusted” are constantly shifting, and new factors (like if Microsoft spots suspicious activity from that user elsewhere) can throw the whole calculation into a new state within seconds.Organizations living through this can run into problems fast. You add a branded Conditional Access policy, think you’ve closed a gap, and then your helpdesk gets calls about users logging in from hotel rooms or coffee shops with no extra challenge. If you pull the logs, you’ll often find that the device was already signed in, or there was some signal Azure AD quietly weighed that overruled your new policy—like the user’s device staying compliant according to Intune, or Microsoft marking the session as low-risk based on recent behavior.So, what’s really happening is less of a hard stop and more of a balancing act. Azure AD considers every possible angle at the point of sign-in. Some signals might get more weight depending on other things happening in your tenant, from an admin rolling out a new policy, to the risk engine flagging an IP address, or even a device getting its compliance check updated five minutes before the user tries again. It’s a live calculation, and it only gets more complicated as you add new apps, new devices, and new users.But here’s something most admins miss: getting through the sign-in experience is just step one. All this heavy lifting—the scoring and the checks—happens right before Azure AD issues what matters most: the access token. Each policy, each signal, each conditional rule—every bit of it feeds into whether Azure AD even hands over a token at all.Once that token exists, there’s a whole new set of concerns. Because the token inherits all those decisions, and sometimes, a well-meaning policy can get quietly overruled or delayed just by the way tokens work in practice. So yes, your policies and signals are working behind the scenes, but it’s the actual token that decides what happens next when that user is roaming the halls of your SharePoint library, even if they started from a hotel lobby. And what’s actually sitting inside that token has huge implications for your overall security stance and how well your controls really work.Inside the Token Factory: Access vs. Refresh (and Why It Matters)Access tokens and refresh tokens pop up everywhere in Microsoft 365 conversations, but in practice, most people treat them as background noise—just digital tickets you need to get work done. That’s how most admins think of them at first, too. The reality is, these tokens run the whole show. If you picture the M365 sign-in process as a conference, the access token is your event badge with your name and session permissions printed on it. You flash it to get into each breakout room—Teams, SharePoint, Outlook. The refresh token, though, works more like a hidden VIP wristband. If your main badge gets old or you try to get into a new session, you just use the wristband to pick up a new badge at the counter, no questions asked—most of the time, nobody notices you’re even swapping it out.But, here’s where things start to get interesting. Not all of these passes are created equal, and the way they interact with Conditional Access policies can make or break your security intentions. Let’s say your organization has rolled out a policy demanding MFA for every sensitive app login. Users with a fresh access token breeze right through, but what about the ones holding valid refresh tokens issued before the policy changed? They’re still moving between sessions, collecting new access tokens, and as long as their refresh token is accepted, they don’t hit the new MFA requirement until that refresh token itself is checked. There’s a built-in lag—sometimes hours, sometimes days—where your new policy hasn’t really landed yet.If we zoom in on the actual contents of an access token, things get granular. Each access token carries a handful of claims—think of them as identity facts: who the user is, which groups they belong to, what device they’re on, sometimes which city they’re logging in from, and critically, the permissions or scopes granted. For SharePoint, this might be read or write access; for Outlook, maybe just read mail. These tokens also have short lifespans by design; in Microsoft’s cloud, an access token typically lasts about an hour. After that, it’s no good. That’s where the refresh token comes in—refresh tokens are longer-lived, usually valid for days or even weeks, and can keep your session alive much longer than the access token alone.Here’s the subtle magic: you hardly ever see a refresh token in action. The Microsoft Authentication Library, or MSAL, does all the heavy lifting for you. As soon as your access token expires, MSAL quietly sends the refresh token to Azure AD, gets a brand-new access token, and applies it to your open apps. You don’t see a prompt or a pause, and you don’t reenter your password or MFA unless something unusual pops up. This “background refresh” means your session can roll along for days—sometimes even surviving a laptop hibernation or a quick location switch—without you flipping your usual routine.The consequence? Your carefully crafted Conditional Access policies don’t catch every user immediately. Let’s talk about that classic MFA rollout scenario. You flip the policy switch, expecting everyone to see a second prompt, but half the company seems to skate by without any new challenge. The answer isn’t that the policy’s broken—it’s that those users are still operating under the rules bundled into their current token set. If their apps haven’t asked for a new refresh token, they won’t see anything different until the refresh token gets checked against Azure AD, and only then do the new policies apply.There’s an obvious risk here. Imagine a situation where a refresh token somehow leaks—say, through a poorly protected personal device, or because a user accidentally installed a shady browser extension. As long as that refresh token is still valid, whoever holds it can keep collecting new access tokens. That might keep granting them entry into apps and data they shouldn’t be anywhere near until either the admin explicitly revokes the session or the refresh token expires on its own. Microsoft is well aware of this. Their guidance isn’t just about shrinking token lifetimes. The recommendation is t

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365–6704921/support.

If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.