[MUSIC]
Stuart Kwan: Welcome back. We’re looking at modern
authentication for native client applications, in this case,
Outlook is trying to get a token to talk to Exchange Online.
In the previous section in Part 1, we looked at interactive
portion of the sign-in where Outlook obtained and
authorization code. Let’s look what happens now as
Outlook performs the non-interactive part of the flow to
finally get a token and then to do things over time.
So now that Outlook has the code, it can send that code
to this other endpoint on Azure Active Directory, which is
the token endpoint. And it will pass along its client ID to
indicate this is, hi, I’m Outlook, the code that it received,
and the fact that, yes, it wants a token for Exchange Online.
The code is actually a form of a short lived security token.
It’s only good with use with Azure Active Directory. And
Azure Active Directory will validate all of this information
and then send back to Outlook an access token
and a refresh token.
It’s the access token that Outlook is finally going to use
when it makes calls to Exchange Online. And it’s going to
send that access token on every request it makes to the
REST endpoint of Exchange Online and it’s going to send it
in what’s called the authorization header of each request.
Exchange Online knows to lift that token out of the
authorization header and by virtue of the fact that it trusts
Azure AD and knows Azure AD sign-in key, it can validate
the signature on the access token, extract the claims, know
that this is our hero Alice, who’s about to check her email
and then do work for Alice, whatever the particular REST
call was. Access tokens are short lived tokens. They typically
only last for about an hour and then they expire. If Outlook
realized, oh, this token is expired or if Exchange tells
Outlook the token you just sent me is expired, then Outlook
needs to get a new access token. And that’s where this thing
called the refresh token comes in. we’re not going to have to
do the interactive authentication again.
All Outlook has to do is take that refresh token and send it
to the token endpoint of Azure AD again along with the
parameter is, hi, I’m Outlook’s client ID. Here’s a refresh
token that I received previously and, again, I want a new
access token for Exchange Online. At this moment, Azure
Active Directory’s going to do all of the usual authentication
checks that it does when it signs you in. It’s going to make
sure that your user account is still valid and still exists.
It’s going to do all of its adaptive authentication checks,
like conditional access checks, identity protection checks.
Maybe the user needs to do a multi-factor authentication
now because previously when they signed in, they were on
a particular network which was trusted, but now they’re on
a network which isn’t trusted. If Azure Active Directory decides
that the user needs to do a new interactive authentication,
then it will send back an error and say, the refresh token
is expired. But if everything else checks out and the refresh
token is still good, then Azure Active Directory will simply
respond back with a new access token and usually a new
refresh token that Outlook is now going to cache and
replace the previously cached version. That’s happens
anytime Azure Active Directory needs to update what’s
in the refresh token that its given to Outlook. And then
Outlook can take the new access token and use it to call
Exchange again.
This protocol sequence, this non-interactive protocol
sequence can go on pretty much indefinitely until Azure
Active Directory decides for one reason or another that
the refresh token is expired. But since it can go on for
a long time, that’s what keeps you signed in on your
mobile device or on your PC in Outlook and not having to
enter your credentials over and over again. It’s this non-
interactive part of the flow.
What we’ve looked at here and the way that we’ve done
this with Outlook and Exchange for modern authentication
is an OAuth 2.0 protocol flow that’s called the authorization
code grant and the kind of client of Outlook is actually called
a public client. And it’s called a public client because Outlook
doesn’t have a secret that it’s using to prove that it is
Outlook to Azure Active Directory. You can’t do that because
the Outlook binary goes everywhere onto your phone and
onto your PC and you could decompile it and extract any
secrets that might be in there. So, there can’t be any
secrets in there and that’s why in the protocol standard,
we call this a public client as opposed to a web server,
which might do a similar flow that can have secrets.
That’s called a confidential client. And that’s the basics
of how modern authentication works with native client
applications.