[MUSIC]
James Poindexter: Hi. Welcome to the Azure AD Architecture
Deep Dive Series.
I am James Poindexter and I’m a Program Manager
on the Azure AD Engineering team at Microsoft.
Swetha Rai: Hello. My name is Swetha Rai and I’m
also a Program Manager on the Azure AD Engineering team.
James: 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 today’s session, we’ll talk about passwordless phone
sign-in using Microsoft Authenticator,
specifically, the process that occurs when a user registers
to use the Authenticator app.
In a later video, we’ll discuss how a user would use the
app to authenticate themselves.
Swetha: Research has shown that a majority of hacking
related breaches use weak or stolen passwords.
At Microsoft, we’re taking a lot of steps towards a future
where passwords are not the default method for
users to authenticate.
We offer three passwordless solutions to our customers:
Windows Hello for Business, FIDO2 security keys,
and the Microsoft Authenticator.
All of these solutions are based on asymmetric cryptography,
where the private keys are securely bound to a single
device and require a local gesture, such as a biometric
or a device PIN to unlock.
James: So, Swetha, when would someone use the
Microsoft Authenticator app over the other offerings?
Swetha: Great question. The Authenticator is best suited
for mobile device based scenarios where users can sign into
work or personal accounts using their mobile devices.
Microsoft Authenticator can be used to perform
multi-factor authentication or MFA for short.
This is done by augmenting the user’s password with a
one-time passcode or a push notification.
To register for MFA with push notifications,
the user can navigate to aka.ms/mfasetup
and scan the QR code on that page.
Once the QR code is scanned, the user’s account will
be automatically added to the Authenticator.
Next, the user is sent a push notification on their device
and upon approval, the MFA services in Azure Active Directory
link the device to the user’s account.
The user is now registered to perform MFA via push
notifications on their mobile device.
The Microsoft Authenticator can also be used as a software
token that allows users to sign into their work or personal
accounts from a mobile phone using a strong user
credential that is tied to a device and uses a biometric
or device PIN.
James: Let’s unpack that a little more. What does it mean
to have a strong user credential?
Swetha: Sure.
A strong authentication is when you can successfully
verify two factors of authentication for a user during the
authentication session.
These factors are something you know, typically a password,
something you are, usually a biometric gesture,
and something you have, typically a device that you own.
When a user registers for passwordless sign-in with the
Authenticator app, a key is generated and stowed on the
device itself and is only accessible by the owner of the
device. This is something you have.
In addition to this, the device owner must use their
device PIN or a biometric gesture to access the key,
thereby satisfying the something you are factor for
authentication.
James: Thanks for explaining that.
Registration is a very simple one-time process,
but there’s a lot happening behind the scenes to
create this seamless experience. Let’s get a better
understanding of what’s happening on the backend.
Swetha: Before the user registers for passwordless
sign-in with Microsoft Authenticator, there are certain
prerequisites they should be aware of to enable this feature.
They will need to set up a device PIN or biometric
gesture on their mobile device.
They will also need to ensure that the device meets the
minimum requirements for OS and hardware capabilities.
When the user enables forms sign-in on the Authenticator
app, the Authenticator will first attempt to acquire a
token with device and MFA claims from authentication
services within Azure AD.
This is the service responsible for handling all of the
authentications within Azure AD.
From here, the authentication services will trigger the
device registration process via device services.
This is the service in Azure AD that is responsible for
registering devices and providing the device with an
identity that can be used to authenticate the device,
where the user signs in.
An important note for registering your device for
passwordless phone sign-in is that the device must be
registered to a tenant and it can only be registered to
one tenant at a time.
This means that you can only have one enterprise
account on the Authenticator at a time, ruling out
shared device scenarios.
James: Just to clear, you can always set up multiple
work or school accounts to perform MFA on the same
device, such as receiving push notifications or one-time
passcodes. The restriction we were just talking about is
only for passwordless phone sign-in.
That’s a great point.
The device registration service will now create a device
object and store it in the core store.
The core store is Azure AD’s main storage, which holds
user data, tenant policies, and much more.
Now that the user has successfully registered their device,
authentication services will trigger an MFA request.
The MFA service will route the MFA push notification
to the Authenticator app via the Apple or Google cloud
messaging system.
The user will then complete an MFA challenge by approving
the notification on their device.
At this stage, since we have a token with device and MFA
claims, an asymmetric key pair is generated on the device,
a public key that will be shared with authentication
services, and a private key that will reside on the
device itself.
This private key will never leave the device,
and it is never shared.
The public key from the generated key pair is exported
and sent to device services, which in turn creates a key
object and places the object in the core store.
The final step in this process is to register the user for
push notifications for passwordless sign-in,
which will result in a better user experience, since the
user will be promptly notified of the challenge.
The notifications are sent to Authenticator app via the
appropriate cloud messaging system for Google or Apple.
James: Now that we are registered to be authenticated
into our account, in a future video we’ll talk about what
happens when you authenticate with this method.
We hope you found this video useful. We will also be adding
more videos on our passwordless offerings, such as
Windows Hello for Business and FIDO2, 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 on the screen.
Swetha: Thank you for watching.
James: Thank you.
[MUSIC]