Configuring Authentication Methods
In this tutorial, we will learn and understand various types of authentication methods in the Azure Active Directory (Azure AD). By using advanced authentication and security features in Azure AD the password can be replaced with additional authentication methods.
Types of Authentication Methods
For primary or secondary authentication, the following approaches are available:
Password
The major authentication methods are referred to by an Azure AD password. The password authentication technique, on the other hand, cannot be disabled. When the user doesn’t use their password to sign in, you can utilize an authentication technique like SMS-based sign-in. Then a password is still an option for authentication.
Microsoft Authenticator app
For Azure AD work or your Microsoft account, the Authenticator app adds an extra layer of protection. Users can sign in without using a password if they utilise this method. It also gives alternatives for verification during self-service password reset (SSPR) or Azure Multi-Factor Authentication events. Users may receive a notification via the mobile app, which they must approve or decline. They can also use the Authenticator app to produce an OATH verification code, which they may input into a sign-in screen. This includes the following:
- Notification through mobile app
By sending a notice to your smartphone or tablet, the Authenticator software can help prevent unwanted access to accounts and erase fraudulent transactions.
- Verification code from mobile app
The Authenticator app may be used to generate an OATH verification code as a software token. You input the code issued by the Authenticator app into the sign-in window after providing your username and password.
FIDO2 security keys
The FIDO (Fast IDentity Online) Alliance promotes open authentication standards and aims to decrease the usage of passwords for authentication. Users who want to utilise FIDO2 security keys can register and then choose a FIDO2 security key as their primary authentication method at the sign-in interface. These FIDO2 security keys are USB-based, but they can also communicate through Bluetooth or NFC.
OATH tokens
OATH TOTP (Time-based One-Time Password) is an open standard that describes how one-time password (OTP) codes are generated. For creating codes, they can use either software or hardware.
- OATH software tokens
Software OATH tokens are similar to the Microsoft Authenticator app or any other authenticator app in that they are programmes. In this case, Azure AD produces the secret key, or seed, which is then used to generate each OTP after being entered into the app. While setting up push notifications, the Authenticator app creates codes automatically. That is, even if a user’s gadget loses connectivity, they have a backup.
- OATH hardware tokens (preview)
OATH TOTP hardware tokens often include a seed, or secret key, that is pre-programmed in the token. These keys must be entered into Azure Active Directory. The secret keys, on the other hand, are restricted to 128 characters, which may not work with all tokens. Characters a-z or A-Z, as well as numerals 1-7, can be used in the secret key. It also has to be encoded in Base32. You should be aware that the resealable programmable OATH TOTP hardware tokens may also be set up using Azure AD in the software token setup flow.
Uploading token in a comma-separated values (CSV) file format including the UPN, serial number, secret key, time interval, manufacturer, and model:
csv
upn,serial number,secret key,time interval,manufacturer,model
[email protected],1234567,1234567abcdef1234567abcdef,60,Contoso,HardwareKey
Phone options
You may configure and enable users for SMS-based authentication through text message for direct authentication. For front-line personnel, the SMS-based sign-in is ideal. Users can access applications and services without having to know their login and password. Furthermore, the user inputs their registered mobile phone number, which is followed by a text message with a verification code, which is then entered in the sign-in interface.
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).
Various verification methods in Phone options include:
Mobile phone verification
For Azure Multi-Factor Authentication, users can choose to receive a text message with a verification code to enter in the sign-in interface. However, if users don’t want their mobile phone number to be visible in the directory but want to use it for password reset, administrators shouldn’t populate the phone number in the directory.
Text message verification
In-text message verification of SSPR or Azure Multi-Factor Authentication, SMS is sent to the mobile phone number containing a verification code. And, for completing the sign-in process, enter the verification code into the sign-in interface.
Phone call verification
In phone call verification during the process of Azure Multi-Factor Authentication, an automated voice call is made to the phone number registered by the user. For completing the sign-in process, the user have enter their pin number followed by # on their keypad.
Email address
An email address 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.
App passwords
If a user has access to multi-factor authentication and tries to authenticate using one of these older, non-browser apps, they will likely fail. An app password, on the other hand, allows users to continue authenticating with older, non-browser programmes without interruption. Users cannot generate app passwords by default. Select Allow users to generate app passwords to login into non-browser apps under Service options if users have access to create app passwords. This is the Azure Multi-Factor Authentication properties for the user.
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 it avoids 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