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 Machine


It’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 to
use risk-based conditional access, apply session controls, and
regularly review sign-in logs for suspicious refresh activity.
Shorter lifespans help, but identifying and disrupting risky
sessions in real time is even more effective.If you look at
session management in the Azure portal or work with PowerShell
scripts, you’ll find options to adjust how long tokens live, how
often users see re-authentication, and how session revocation
works in practice. The trick is that there’s always a trade-off
between user productivity and security—chopping token lifetimes
too aggressively can frustrate users; making them too long can
open risk windows. The decision often comes down to what’s
happening in your environment: how mobile your workforce is, how
sensitive your data is, and how often security threats actually
appear on your radar. The real lesson? Token management isn’t a
minor detail—it’s the backbone of your entire security and
productivity balancing act. Policies look strong on paper, but if
you don’t interrupt the token lifecycle, your changes take longer
to matter. The decision to force session revocation or device
compliance isn’t just a checkbox—it’s what decides who gets in
quickly, who waits, and who gets blocked outright. But let’s push
this further: what if you change your Conditional Access rules in
the afternoon—can you really force those changes to take effect
instantly, everywhere? Or do the existing tokens quietly defy
your new guardrails until their built-in timer runs out? Most
real-world environments see a lag, and that’s where both risk and
confusion creep in. The token lifecycle, in practice, plays a
huge role in whether or not your security posture actually
matches what you wrote in the admin portal. And as you start
tweaking policies mid-game, those hidden tokens may decide to
play by their own schedule.


Changing the Rules: Conditional Access Meets the Token Lifecycle


If you've ever spent a weekend tightening your Conditional Access
policies only to find users are still walking through what should
be airtight doors, you’re not alone. It feels like a cruel
trick—flip a policy switch, tell leadership the environment is
secured, then check the logs and spot a user happily logging in
from Bali. What's actually happening is less about Azure AD
ignoring your intentions and more about how the token system
enforces (or delays) every rule you put in place.Let’s look at
what’s really behind that delay. You decide to require MFA for
any login outside your country. It’s a straightforward rule and,
in theory, users on vacation should suddenly need their
Authenticator app. But users who already signed in last week?
They’re still opening Outlook and OneDrive on the same old
devices, with nothing new popping up. This isn't because
Conditional Access missed them—it's because those users are
relying on tokens that were minted before your rule got stricter.
Conditional Access only kicks in when a new token is being
issued. If there’s already a valid access token, Azure AD doesn’t
force a new evaluation until absolutely necessary.The heart of
the issue is timing. Access tokens stick around for a set window,
often an hour, sometimes more depending on what your environment
allows. During that time, the token simply says “yes, this person
is trusted as of when the token was created.” Any major policy
changes are sitting on the sidelines, unnoticed, until the next
refresh. It’s only when the access token expires, and the app
presents the refresh token, that Azure AD rechecks all your
Conditional Access policies and decides if the user still
deserves a seat at the table.I’ve watched admins roll out updated
location policies at financial firms—the kind where new rules
should keep remote users out if they’re bouncing between Wi-Fi
hotspots in different countries. Even after the change, people
keep downloading quarterly reports from places the company is
trying to block. Hours tick by with users sneaking through on
access tokens that are still valid. In regulated industries, that
means the risk window stays open far longer than the compliance
folks would like.Session management policies do give you a lever
to force these rechecks earlier. By cutting access token
lifetimes down to the shortest reasonable window, you make it
more likely users will have to present their refresh tokens and
hit your new policies. Forcing sign-outs or revoking refresh
tokens through the Azure AD admin portal can have an immediate,
if sometimes disruptive, effect. That’s often the nuclear option
when you need everyone logged out right away—say, during a
security incident or a sudden policy overhaul. These approaches
work, but there’s a price: users might start complaining about
having to log in repeatedly, or mobile apps suddenly lose their
connection in the background.If you’re comfortable with
PowerShell, you get a bit more control. Commands like
`Revoke-AzureADUserAllRefreshToken` allow you to target a single
user or group and cut off their refresh tokens instantly. The
downside is scale and tracking—you have to know who’s at risk,
and you’re in the business of chasing sessions by hand. This is a
maintenance burden for any large environment.Within the Azure AD
portal itself, session controls let you tweak the default
expiration, but you’ll hit hard limits. Some apps, especially
those using legacy authentication stacks or custom integrations,
might not respect those settings cleanly. And that’s before you
even get into how persistent browser sessions or alternative
sign-in flows might bypass re-authentication hints
entirely.Things get even messier with mobile devices and
background services. Many modern apps—Teams, Outlook Mobile,
OneDrive—are built around silent background token refresh. That
means users enjoy near-invisible connectivity, but every time you
push a new policy, it can be hard to force an immediate
reevaluation unless you’re willing to disrupt live sessions.
Mobile apps are notorious for holding on to refresh tokens,
sometimes even after a device is wiped unless you’ve put strong
device management in place.So, to actually make new rules stick,
you can’t just rely on publishing policies and hoping for the
best. You have to cut off old tokens or dramatically shrink their
lifespan. Otherwise, there’s a real gap between what’s written in
policy and what’s felt by users. Each untouched session is
running on decisions baked into the old token, no matter how good
your intentions were when you crafted the update.What you’ll end
up wrestling with is how to keep tight security without crushing
productivity. The quicker you force token refresh, the faster
your rules spread—but at a cost. Forced logouts frustrate users
and can disrupt meetings, data syncs, or app launches. There’s no
perfect answer. For environments handling sensitive data, the
risk of lagging sessions often outweighs the downside. Others
play it more conservatively and choose to let tokens expire on
their regular schedule.As Zero Trust strategies take hold, the
traditional ways of managing these “permission gaps” start to
fall short. Dynamic, always-on validation is the new goal. But
right now, even the best Conditional Access policy is only as
good as the tokens it can reach, and that’s why knowing exactly
when and how those tokens update is where your leverage truly
lives. When Zero Trust comes into play, suddenly every access is
supposed to be up for reevaluation—pushing us all toward
shorter-lived tokens, frequent reauthorizations, and a bigger
shift in how Azure AD handles trust over time.


Zero Trust and the Future: Dynamic Tokens in a Changing M365
World


Zero Trust has become one of those phrases that gets thrown
around in every Microsoft 365 conversation, but once you start
rolling it out, the reality is pretty different than the sales
pitch. Somewhere between the eighth Conditional Access policy and
your fourth “is this really required?” meeting, you start to
notice things aren’t as predictable as they used to be. Ask any
admin who has shifted their environment to Zero Trust—a day after
the change, users are flooding the support channels with
questions about odd login prompts. Some folks get challenged for
MFA at what feels like random times, while others glide through
as if nothing changed at all. Even IT staff get caught off guard
by logins that worked one day and suddenly ask for something
extra the next morning. It’s not a bug; it’s how Zero Trust is
supposed to work now.The core shift is that Zero Trust wipes away
the old “authenticate once, access everything” assumption. Now,
every access is up for review. Every click, every request to
SharePoint or Teams or Outlook is run through a context
check—location, device state, risk signals, and more—before Azure
AD hands out a new access token. You can’t rely on the idea that
a user’s token from two hours ago still makes sense, especially
if something in their situation changes. Instead of only checking
at sign-in, Azure AD and MSAL are evaluating trust in near
real-time. If you open a sensitive app from home one evening,
then walk into a new location the next morning, don’t be
surprised if you’re asked to reauthenticate—your environment
looks different now, so the system is actively challenging
whether you still meet the requirements.Conditional Access
becomes much more than a blunt instrument in this setup. Rules
aren’t just “on” or “off.” They get triggered by evolving
signals. For example, say your laptop leaves corporate Wi-Fi and
connects to coffee shop internet. That location flag combines
with a device health change, maybe an overdue Windows update, and
Azure AD recalculates trust on the spot. Suddenly, instead of
letting that access token ride until it expires, the system can
force a prompt right in the middle of a session. This is possible
because of how MSAL and Azure AD work together now—dynamic claims
are added to the access token, reflecting the latest state of the
user, the device, and even external risk intelligence from
Microsoft.It’s not just user signals that matter anymore, either.
App registration permissions are front and center in determining
what happens next. Think about a finance app someone built
internally that now wants to access new data from SharePoint or
Teams. The permissions set when that app was first registered are
baked into every token the app receives. That means a user who is
compliant and risk free only gets as much access as the app’s own
registration allows. Flip the switch on app permissions and
suddenly even the most trusted user can’t see certain data. It’s
a layer that trips up organizations who assume users alone
control their access—apps and permissions are just as critical to
manage as users and devices.Network location has become a living,
breathing signal in all of this. In the past, logging in from a
new IP address might have triggered a single prompt. Now, that
change can adjust your risk score on the fly. If Microsoft
detects a login attempt from a city you’ve never visited,
real-time intelligence can challenge or even block access
immediately. It’s not just about blocking based on a static list
of countries; it’s about responding to what looks suspicious in
context, even if that means one user gets through and another is
stopped—because their recent activity signals different
risk.Let’s take a real example from a hybrid work rollout. An
organization shifts to Zero Trust, enabling continuous evaluation
policies in Azure AD and trimming token lifetimes for cloud apps.
Employees who used to rely on persistent sessions find that their
access is broken up regularly—especially if they bounce between
home, office, or remote meeting locations. The IT team gets
questions as to why users are being re-prompted more frequently
or why certain apps stop working after a change in device
compliance. Digging into the logs, admins notice that token
renewal is getting blocked not just by traditional Conditional
Access policies, but also by live risk signals about device
health or flagged behavior.Suddenly, even small changes to a
policy have outsized impacts. An updated device compliance
requirement, a new partner country on the block list; both can
ripple out and cause a surge in authentication prompts, support
tickets, or failed app launches. It’s adaptive, but it isn’t
automatic magic—every policy tweak needs to be weighed against
the day-to-day disruption for real users trying to stay
productive.This landscape demands careful planning. The tools are
more powerful, but the margin for error is tighter. The system
adapts to new threats and user behavior in real time, but the
loops between policy, signal, and user experience are now short
and very visible. If you’re running a busy tenancy, every change
is felt almost immediately by someone. Zero Trust isn’t a feature
you turn on; it’s a constant tuning process that challenges you
to keep your environment secure without grinding everyone to a
halt. With tokens and policies becoming more interconnected and
responsive, it’s less about setting it and forgetting it—and more
about continuous health checks for your entire authentication
setup.


Conclusion


If you’ve ever assumed Modern Auth was just toggling some
settings and calling it done, you’re missing most of the picture.
Every part—tokens, policies, signals, and device checks—plays a
role in whether your users hit a wall or coast through. When you
really see how these pieces talk to each other, you’re much
better prepared to build something secure without driving
everyone crazy. Next time you update a Conditional Access policy,
stop and dig into what tokens your users still hold and what
sessions are quietly running on yesterday’s trust. That’s where
the real story always surfaces first.


Get full access to M365 Show - Microsoft 365 Digital Workplace
Daily at m365.show/subscribe