Methods for authentication in Azure Active Directory
Exam AZ-304 is retired. AZ-305 replacement is available.
In this, we will learn about the sign-in experience for accounts in Azure Active Directory (Azure AD) for which users can authenticate. Moreover, we will understand the various methods available for authentication.
However, a username and password is the most common way a user would historically provide credentials. But, with modern authentication and security features in Azure AD, that basic password can be supplemented or replaced with additional authentication methods. A user in Azure AD has access to choose the authentication way using one of the following authentication methods:
- Firstly, Traditional username and password
- Secondly, Microsoft Authenticator App passwordless sign-in
- Then, OATH hardware token or FIDO2 security key
- Lastly, SMS-based passwordless sign-in
There are many accounts in Azure AD that are running for self-service password reset (SSPR) or Azure Multi-Factor Authentication. These features include additional verification methods, such as phone calls or security questions. To better understand this, below the types of authentication list is provided. So, let’s learn about it.
Methods for Authentication
There are various methods available for primary or secondary authentication, let’s start with the first one that is Password.
1. Password
An Azure AD password is one of the primary authentication methods. However, you can’t disable the password authentication method. Even if you use an authentication method such as SMS-based sign-in when the user doesn’t use their password to sign, a password remains as an available authentication method.
2. Microsoft Authenticator app
The Authenticator app is for providing an additional level of security to your Azure AD work or school account or Microsoft account. This app is available for Android, iOS, and Windows Phone. Moreover, using this app, users can authenticate in a passwordless way during sign-in or as an additional verification option during self-service password reset (SSPR) or Azure Multi-Factor Authentication events.
- In this, the users will receive a notification through the mobile app for them to approve or deny. Or they can use the Authenticator app to generate an OATH verification code that can be entered in a sign-in interface. However, if you enable both a notification and verification code, users who register the Authenticator app can use either method to verify their identity.
- Next, the user can get a verification code from a mobile app. In this, there is the use of the Authenticator app as a software token to generate an OATH verification code. After entering your username and password, you enter the code provided by the Authenticator app into the sign-in interface.
3. FIDO2 security keys
The FIDO (Fast IDentity Online) Alliance helps in promoting open authentication standards and reduce the use of passwords as a form of authentication. However, FIDO2 is the latest standard that incorporates the web authentication (WebAuthn) standard. In this the users can register and then select a FIDO2 security key at the sign-in interface as their main means of authentication. These FIDO2 security keys are typically USB devices, but could also use Bluetooth or NFC. However, with a hardware device that handles the authentication, the security of an account can be increased.
4. OATH tokens
OATH TOTP (Time-based One Time Password) refers to an open standard that specifies the generating process of the one-time password (OTP) codes. For this, implementation is done using either software or hardware to generate the codes.
OATH software tokens
Software OATH tokens are typically applications just as the Microsoft Authenticator app and other authenticator apps. In this, Azure AD generates the secret key, or seed, that’s input into the app and used to generate each OTP. Then, the Authenticator app automatically generates codes when setting up for doing push notifications so a user has a backup even if their device doesn’t have connectivity. Third-party applications that are using OATH TOTP for generating codes can also be used.
OATH hardware tokens
Azure AD supports the use of OATH-TOTP SHA-1 tokens that refresh codes every 30 or 60 seconds. However, OATH TOTP hardware tokens typically come with a secret key, or seed, pre-programmed in the token. And, the secret keys are limited to 128 characters, which may not be compatible with all tokens. Moreover, these secret keys can only contain the characters a-z or A-Z and digits 1-7 and must be encoded in Base32. Users may have a combination of up to five OATH hardware tokens or authenticator applications, such as the Microsoft Authenticator app, configured for use at any time.
5. Phone options
For authentication using a text message, the user can Configure and enable users for SMS-based authentication. Moreover, the SMS-based sign-in is great for front-line workers in which users don’t need to know a username and password to access applications and services. As the user only enters their registered mobile phone number, receives a text message with a verification code, and enters that in the sign-in interface. Moreover, users can also verify themselves using a mobile phone or office phone as a secondary form of authentication used during Azure Multi-Factor Authentication or self-service password reset (SSPR). For working properly, phone numbers must be in the format +CountryCode PhoneNumber.
6. Text message verification
In-text message verification of SSPR or Azure Multi-Factor Authentication, SMS is send to the mobile phone number containing a verification code. And, for completing the sign-in process, the verification code is entered into the sign-in interface.
7. Phone call verification
In phone call verification during SSPR or Azure Multi-Factor Authentication, an automated voice call is made to the phone number registered by the user. To complete the sign-in process, the user is prompted to enter their pin number followed by # on their keypad.
8. Security questions
You should know that security questions aren’t used as an authentication method during a sign-in event. But, they can be used during the self-service password reset (SSPR) process to confirm who you are. However, administrator accounts can’t use security questions as verification methods with SSPR. Firstly, when users register for SSPR, they’re prompt to choose the authentication methods to use. And, if they choose to use security questions, they pick from a set of questions to prompt for and then provide their own answers. Not to mention, but security questions can be less secure than other methods because some people might know the answers to another user’s questions. So, if you use security questions with SSPR, then use them in conjunction with another method.
Security question requirements
For both default and custom security questions, there are requirements and limitations that applies:
- Firstly, the minimum answer character limit is three characters.
- Secondly, the maximum answer character limit is 40 characters.
- Thirdly, users can’t answer the same question more than one time. Moreover, they cannot provide the same answer to more than one question.
- Fourthly, any character set should define the questions and the answers, including Unicode characters.
- Lastly, the number of questions must be greater than or equal to the number of questions that have gone through registration.
9. Email address
An email address does not act as a direct authentication method. However, it is only available as a verification option for self-service password reset (SSPR). When there is a selection of an email address during SSPR. Email is received by the user for completing the authentication/verification process. While registering for SSPR, a user provides the email address to use. But, they should use a different email account than their corporate account to make sure they can access it during SSPR.
10. App passwords
If a user has access for multi-factor authentication and attempts to use one of these older, non-browser apps, they usually can’t successfully authenticate. However, an app password allows users to continue to successfully authenticate with older, non-browser apps without interruption. By default, users can’t create app passwords. If users have access to create app passwords then, select the Allow users to create app passwords to sign into non-browser apps under Service settings. This is for user’s Azure Multi-Factor Authentication properties.
If your organization is federate for single sign-on (SSO) with Azure AD and you use Azure Multi-Factor Authentication, the following considerations apply:
- Firstly, the app password is verified by Azure AD, so bypasses the federation. That is to say, Federation is only used when setting up app passwords. And, for federate (SSO) users, passwords storage is in the organizational ID.
- Secondly, On-premises Client Access Control settings are not fulfilled by app passwords.
- Thirdly, no on-premises authentication logging or auditing capability is available for app passwords.
- Lastly, certain advanced architectural designs may require using a combination of organizational usernames and passwords. Moreover, it also includes app passwords when using multi-factor authentication, depending on where they authenticate.
Reference: Microsoft Documentation