Leveraging Microsoft Authenticator as a Possession Factor with Okta

Please read the disclaimer first before you start implementing the approach

DISCLAIMER: Okta Documentation mentions that configuring Microsoft Azure Active Directory (AAD) can’t be used as an IDP Authenticator. This article will test that statement hence if you decide to implement this in your own Okta production org/instance and got into any production issues, Okta will not in any means support this deployment. Hence, WORK AT YOUR OWN RISK.

Credits to my colleague Anand Chinnachamy in formulating this idea and also helping me setup this in my own Okta instance

—————————————————————————-

18th June 2024 – updates: If you’re getting an error in Okta saying unable to retrieve access token, this error is being generated because there is a custom claims mapping set within your OIDC application in Azure AD/Entra. To resolve this issue, you need to navigate to the Enterprise application of your OIDC Application in Entra.

Click Edit and make sure no custom claims or mapping is set. If there is one, please remove that such that you get to this kind of configuration

——————————————————————————–

This article aims to showcase how organisations can slowly migrate away from Microsoft Authenticator as the 2FA/MFA to Okta with less end-user changes and friction.

Microsoft is under heavy scrutiny, thanks to Storm-0558 which is the latest Microsoft Intrusion, on how they operate and provide security to their customers or organisations using Microsoft Security Products, and Entra ID falls within this space.

If you are a Microsoft customer or organisation that is getting weary with Microsoft and you’re looking for something better, Okta Workforce Identity Cloud would be an option you can consider to serve as the Identity Fabric and anchor point for your Zero Trust Security controls.

The biggest challenge most organisations face is how they can seamlessly replace and migrate the existing 2FA/MFA authenticator as most of their end-users have already deployed it and they want to do a slow or trickle swap out.

Microsoft is known for being notorious for not allowing any 3rd party vendor to integrate with their MFA/2FA Authenticator application, which is Microsoft Authenticator.

I’ll show you a easy way on how you can still allow your end users to keep using Microsoft Authenticator as the 2FA/MFA provider in Okta and eventually replacing it out with Okta’s own Authenticator which is Okta Verify.

Step 1: Configure an App Registration within your Entra Portal and name it as Microsoft Authenticator Provider for Okta

Step 2: Create a client secret. Take note of the client secret

Step 3: Navigate to Overview and take note of the Application (client) ID and Directory (tenant) ID.

Step 4: Navigate to API permissions and make sure you click Grant admin consent for your tenant

Step 5: Within Microsoft Azure, search Authentication methods. Click that

Step 6: Within Entra Authentication Methods, Policies page should be displayed. Select Microsoft Authenticator

Step 7: Click the enable toggle button and make sure authentication mode is set to Any. Optionally, you can filter which users you want to apply this policy.

Step 8: Navigate to Entra Conditional Access Policy and create a conditional policy that will enforce Passwordless-only challenge. This can be done by specifying ‘Require Authentication strength, and setting Passwordless MFA as the value’

In this example, I’ve assigned the conditional access policy to all cloud apps.

Step 7. Login to your Okta Admin Console and Navigate to Security->Identity Providers

Step 8: On-board a OIDC Provider

Provide a name like Microsoft Authenticator as a Provider

Change the IdP usage as Factor Only. Supply the Client ID and Secret you’ve obtained from Entra App Registration

For the Endpoints, refer to https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration and supply the necessary information

Step 9: Navigate back to Security->Identity Providers. Take note of the Redirect URI Use those values and paste it back to Microsoft Entra ID app registration page.

Click Redirect URIs and click add platform (WEB). You don’t need to tick the ID or Access Token options.

Step 10: Within Okta, Navigate to Authenticators->Setup. Click Add Authenticator.

Select IdP Authenticator. Click Add and select the Microsoft IDP Authenticator we’ve on-boarded.

You can even upload an image of it. Click Upload once finalised and click Add.

Step 11: Let’s make an enrolment policy that will enforce the Microsoft Authenticator as IdP for my end users. I’ll make the Microsoft Authenticator IDP as required for now and make Okta Verify as Optional

Step 11: Try it out. Take note that the username and email in Okta needs to match the UPN from Azure AD/Entra for this to work.

REQUIRED EXTRA STEP: You Azure AD/Entra ID administrator should have enabled Phone Sign In option within the ENTRA ID settings. End users should also have enabled Phone Sign In such that this will work. If the end-users haven’t enabled Phone Sign In then this experience will not work.