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. And 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 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're going to use the same thing to do the same thing. 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, 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 ADFS.
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, 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 a 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 WebView. And the WebView is going to be a little bit more complicated.
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 dialogue 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 web view. 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 the 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.0 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, at 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 ADFS 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 ADFS 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. She sees the sign in page from ADFS 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. ADFS server, the ADFS 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 signing key of ADFS, 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 authentication authorization code request by sending the authorization code, which is what Outlook is going to need, by sending it in the 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 WebView 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 WebView 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 OAuth2 protocol.
The WebView 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 terms of use.
All of that stuff happens in the interactive surface of the web view. In part two 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 two.