[MUSIC]
Swetha Rai: Hello, and welcome to Azure AD Architecture
Deep Dive Series. I’m Swetha Rai and a Program
Manager on the Azure AD Engineering team at Microsoft.
James Poindexter: And I’m James Poindexter, also a
Program Manager on the Azure AD Engineering team.
Swetha: We are part of the Customer Experience team
and we help enterprises and businesses from all over the
world to deploy our services and get to the cloud.
We get a lot of questions about how Azure AD works
under the hood, which we will share with you throughout
this architecture series.
In the last video, we discussed the registration process
for passwordless phone sign-in on the device using the
Microsoft Authenticator.
In today’s session, we’ll take a deeper look at the
process that occurs when a user signs in using the
Microsoft Authenticator.
At this point, we’re assuming that the user has registered
for passwordless phone sign-in.
If you’d like to know more about this process,
please see our previous video on registering for
passwordless authentication with Microsoft Authenticator
or visit aka.ms/passwordless.
James, want to get us started?
James: So, let’s say our user wants to sign into their
work account to access a company resource and they
have not authenticated just yet.
After typing the username on the web page and selecting
next, users are presented with a number and are prompted to
match that number on their mobile device.
If successful, they will be granted access instead of having to
use their password.
Now, let’s take a look at what is happening behind the scenes.
In our previous example, our user wants to access some
company resource. When they type in their user principal
name and submit it to Azure AD, authentication services
determines that the user is attempting to sign in using
Microsoft Authenticator.
Authentication services will then generate a few things.
To start, it will create a session for this authentication.
Additionally, it will generate a set of three pseudo
randomly generated two-digit numbers.
One number will be sent to the browser to be displayed
on the web page, while all three numbers will be sent to the
Authenticator app via a push notification through the Apple
or Google cloud messaging system.
The user is then presented with three numbers that
they must match with the number shown on the browser.
The user could also choose to deny the request,
which terminates the session and, thus, the authentication.
When the user selects the code displayed in the
Authenticator, they will then be prompted for the device
PIN or biometric gesture. The device PIN or biometric
gesture is used to access the private key on the device.
Swetha: So, James, why do we require the user to
match the number when the private key is only
accessible with the device PIN or biometrics?
James: Great question.
From a technical perspective, the private keys can only
be unlocked and accessed through the device PIN or
biometrics. This additional step is simply proof of
presence, that you are in front of the browser so that
you do not accidentally approve the wrong notification.
A nonce is then signed using the private key and returned
to authentication services, which then verifies the signed
nonce and checks if the user correctly matched the
number on the Authenticator.
Finally, once authentication services validates the signed
none and the number selected by the user, it generates a
token and presents it to the browser.
At this point, the user is authenticated to access the
resource and this completes the flow.
Swetha: We hope you found this video useful.
We will also be adding more videos on passwordless
offerings, such as Windows Hello for Business, FIDO2
security keys, as well as other topics, like provisioning,
governance, and many more.
If you want to get a copy of the diagrams we used today
or want to give us feedback and help us figure out what to
cover, please follow the link in the description below.
James: Thanks for watching.
Swetha: Thank you. [MUSIC]
