[MUSIC]
Stuart Kwan: Hi. I’m Stuart Kwan. I’m a Program Manager
in the Azure Active Directory team and in this video, we’re
going to take a quick look at modern authentication for
native clients. When I say native client, I mean an
application like Outlook running on your phone or on your
PC. How does it do the modern authentication dance of
getting a token and sending it to a service to authenticate
a user?
Now in this particular segment, I’m going to use a different
way of modeling the scenario. Instead of drawing bubbles
with trust relationships, I’m going to use a thing called a
message sequence diagram or a protocol sequence diagram.
It’s a really handy tool for when you’re trying to map out
exactly what the interactions are that are happening between
a set of players in a protocol sequence. And it’s a lot easier
to follow in many cases than those bubble diagrams I was
using before.
The way that we’re going to do this is by bringing out each
of the players. So, the two heroes here are Outlook that is
going to be our client, and then we’ll also have Exchange,
which is going to be the place that we’re actually going to
go with the token so that Outlook can check your mail or
you can check your calendar or what have you. Now, we
need a few more players here for this to work. We need to have
Azure Active Directory as the identity provider for Exchange
Online. And just to make this exciting, we’ll also have a
federated scenario. So, we’ll have Active Directory and AD FS.
And then finally, we’re going to need one other player here
that I’m going to describe in a moment that’s going to be
part of the client interaction. So, once you’ve got all of your
different players laid out in boxes across the top of your
sheet of paper or your whiteboard, then what you do is you
draw these endpoints that represent the different places
where we’re going to send and receive messages. And this
is how we’re going to formulate the protocol sequence.
So as we know in modern authentication, the goal is for
Outlook to get a security token and send it to Exchange.
And really, the first thing that Outlook does when it wakes
up and wants to do something with your mail, is it looks in
the cache that it has to say, do I have any tokens I can use
for this? And in this example, we’ll say no. It doesn’t have
any tokens in its cache, so it needs to do an authentication
sequence. And it’s going to use a little helper here that’s
called a web view. And the web view is a browser that is
tethered to the application, if you will. Years ago, these
web views were actually controls that lived inside the Outlook
process and they would open in front of Outlook, so you could
see a web surface in a dialog or such inside your application.
In the past several years, the mobile operating system
providers have created a thing called a system web view
which runs out of process of Outlook but still appears to
be a dialog as part of an application and it allows you to
have a better security so that when a user is entering
credentials or something in that web view, the key
presses aren’t visible to the application. So, this is a system
web view. And Outlook is going to open this system web
view and then it’s going to navigate it to Azure Active
Directory. There’s actually two lines that I need to have
drawn here for Azure Active Directory. It’s going to
navigate to Azure Active Directory and issue what’s called
an OAuth 2.0 authorization code request. And again, that’s
just doing a get on a URL that has in its query string
parameters the parameters of the OAuth 2 request.
So, that is going to be a navigation to what’s called the
authorization endpoint of Azure Active Directory. And
there’s no cookie in the web view, so there’s no session
that has been previously established. Azure AD doesn’t
know who the user is, so it’s going to display the sign-in
page to the user. And then that’s what comes back and
gets displayed in the web view. And we’ll just draw the
display as if it was there. And let’s say that it was our hero,
Alice, again who wants to sign in and she enters her name
alice@Contoso.com. And as we discussed in the federation
variant of the video, we know that when this information is
sent back to Azure AD, it can use it to do home realm
discovery and realize that, oh, contoso.com is a federated
domain. I need to send an authentication request to AD FS
to log this user in, to sign this user in.
So, that again is a message that goes through Alice’s
browser and then Alice sees the sign-in page from AD FS.
Because, again, there’s no state that’s been previously set
up. In the web view, there’s no cookies, so Alice needs to
sign in. As she sees the sign-in page from AD FS, and just
for the sake of example, we’ll say she enters her password
here on the sign-in page and that gets sent back to the
AD FS server. The AD FS server says, yes, this really is
Alice. It’s okay to sign her in and it responds to that
authentication request that came from Azure AD. And again,
this is usually a post of a token—we’ll call it t1—back to
Azure AD that represents Alice’s identity. Because Azure
AD has a trust relationship and knows the sign-in key of
AD FS, it can validate the signature on the token and know
that this is Alice. At that moment, it does all of its other
adaptive authentication checks, conditional access checks,
if she’s on this network, maybe she needs to do
multi-factor authentication. Is her account still valid? All
of the usual things that it does, but if it decides that Alice
really is legit and can sign in, then it’s going to terminate
this original authorization code request by sending the
authorization code, which is what Outlook is going to
need, through by sending it in a query string parameter
to what’s called the redirect URI of Outlook. Outlook is
registered with the directory and when Outlook was registered
with the directory, it said, when you need to send me
authorization codes, you need to send them to this redirect
URI. The redirect URI doesn’t actually exist on the internet.
It’s a sign that when the web view navigates to the redirect
URI, that the protocol has completed and the authorization
code is in a query string parameter on that call.
So, back to the web view comes that authorization code.
Oh, and I forgot to mention earlier, in this call the
parameters that we’re going to see are things like the
Outlook client ID, the fact that I need an authorization
code, and that I’m asking for a token for Exchange Online.
That’s all in that original authorization code request.
And then finally, what’s coming back to the redirect URI
is that authorization code, which is part of the OAuth 2
protocol.
The web view now knows that its job is done, so it closes
and returns the authorization code to Outlook. And that
ends the interactive part of the sign-in where Alice in the
web view is doing things like federated authentication,
adaptive authentication, maybe she needs to do
multi-factor, maybe she needs to answer a terms of
use, all of that stuff happens in the interactive surface of
the web view.
In Part 2 of this video, we’re going to take a look at what
happens in the non-interactive section of this protocol
where Outlook finally gets the token that it needs to talk
to Exchange. So, I’ll see you in Part 2.