Azure AD certificate-based authentication (CBA) is an authentication method that lets you, as a business, require your system users to authenticate their identity directly through X.509 certificates. The certificates are authenticated against your Azure Active Directory (Azure AD) to allow application access and browser sign-in.

This method of authentication is much more secure than the standard username and password authentication. Whether you’re trying to remain compliant with industry standards, have concerns about intellectual property and trade secrets, or you’re just passionate about security – Azure AD certificate-based authentication may be the right choice for you. Read on to learn more.

What Is Azure AD Authentication?

Before cloud-managed support for CBA, users had to use federated certificate-based authentication. This means that to authenticate their X.509 certificates against Azure AD, they had to deploy Active Directory Federation Services (AD FS).

With Azure AD certificate-based authentication, you can cut out the middleman and authenticate your certificates directly against Azure AD. This streamlines the user experience and reduces the cost of operating and maintaining your environment.

The Benefits of Using Azure AD CBA

Better User Experience

Instead of taking extra steps and waiting for multiple connections, users who need certification-based authentication are able to authenticate directly against Azure AD without having to run and pay for federated AD FS.

The user interface of the portal allows you to easily and intuitively configure and map your certificate fields to a user object attribute, allowing you to look up the user in the tenant. This means you can create unique usernames and bind certain certificates to those users specifically – a feature that reduces phishing scams and password hacking while also reducing steps for your users.

You can also use the portal’s user interface to configure authentication policies around your authentication preferences. You can decide if your organization prefers single- or multi-factor authentication.

Easy Implementation

Azure AD certificate-based authentication is free to implement and use. There are no complex deployments or on-site network configurations required. And since this method allows you to authenticate directly against Azure AD, it eliminates extra steps through direct communication.

Heightened Security

Direct authentication eliminates the need for on-premises passwords to be stored in the cloud. This lowers the likelihood of your users being hacked or phished since their credentials cannot be easily captured.

Your users are even further protected by Azure AD Conditional Access policies like Phishing-Resistant multi-factor authentication (MFA) and blocking legacy authentication. These policies are automatically integrated with Azure AD CBA.

How Does Azure AD Certificate-Based Authentication Work?

If we break down the actual steps that a user takes to use Azure AD CBA, it looks something like this:

1. The user attempts to access an app such as Outlook or OneDrive.
2. The user is directed to the User Sign-In page (if they are already logged in, they will be redirected to the app in question).
3. The user will be prompted to enter their username and click “Next”.
4. Once the “Next” button is clicked, Azure AD completes home realm discovery based on the tenant name and the unique username is run against Azure AD.
5. Azure AD then checks if CBA is enabled for the tenant. If it is, the user will see a link to “Use a Certificate or Smartcard” on their password window.
6. Once the user selects the certificate option for authentication, the client is redirected to the certauth endpoint where it performs TLS mutual authentication.
7. Next, Azure AD requests a client certificate, which the user can choose from the selection shown to them. After a certificate is chosen, the user selects “OK”.
8. Azure AD then ensures that the certificate is valid and not revoked based on the username binding on the tenant map.
9. Based on the way your organization is set up, the user will then either be signed in automatically or prompted to complete Azure AD Multi-Factor Authentication
10. Once this is complete the user should be signed in and have access to the application.

This is a complex process when you break down the technical steps, but the user should only experience a few seconds of screen prompts to sign in and start using their application.

FAQs

What are the available Azure AD MFA authentication methods?

Sometimes, an organization may want the extra security provided by a second form of identification in the sign-in process. If you opt for multi-factor authentication (MFA), there are several ways you can have your users complete the process:

• SMS (text)
• Voice call
• Microsoft Authenticator app
• Windows Hello for Business
• Security Key
• SmartCard
• OATH hardware token (preview)
• OATH software token

The Azure Active Directory MFA options are meant to help further secure the sign-in process. While it may take a few extra moments for your users, it does provide another layer of security for your systems.

What can I use Azure AD CBA for?

There are many supported scenarios for Azure AD CBA, including user sign-ins to web browser-based apps, Office mobile apps, and mobile native browsers. You can also create custom certificate-to-user account bindings using any of the certificate fields.

This means that you can sign into any network-supported app or browser with just one sign-in at the beginning of the day. This saves your users time, effort, and frustration.

Can I use non-HTTP URLs for CDP?

No. Only HTTP URLs can be used. No OCSP or LDAP URLs are compatible.

Learn More

Axiad adds a unified passwordless, phishing-resistant MFA to the CBA approaches of multiple IAM approaches including Azure AD and Microsoft Active Directory (AD). Further, Axiad provides a critical capability – credential management at scale to help organizations migrate to Azure AD. To learn more, please visit our Certificate-Based Authentication for IAM page.