If you’ve ever tried to let EntraID (Azure AD) guest users sign in to an Okta-protected app via the built-in Microsoft IdP, you’ve probably hit a wall. The login flow either drops the user on a personal Microsoft account screen or fails outright with a confusing error.

The root cause is simple: guest accounts (B2B) live in a specific tenant, but Okta’s default Microsoft IdP talks to the common endpoint, which assumes the user can be discovered globally. Here are the notes I keep handy when wiring this up.

Why the default Microsoft IdP fails for guests

#

Okta’s out-of-the-box Microsoft IdP is pre-configured against the multi-tenant endpoint:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize

The /common endpoint relies on Microsoft’s home realm discovery: it inspects the email entered by the user and routes the authentication to the tenant where that identity lives. For a guest, the email (alice@example.com) resolves to a personal Microsoft account namespace, not the inviting tenant. The result is the classic error:

You can’t sign in here with a personal account. Use your work or school account instead.

…unless the user happens to also own a personal Microsoft Account with that email — in which case they’ll authenticate against the wrong identity and Okta will receive a token that has no relationship with your tenant.

Fix: use a tenant-specific Custom OIDC IdP

#

The solution is to bypass /common and pin the authentication to your tenant by using its tenant ID (a GUID, found in EntraID → Overview). This forces Microsoft to authenticate the user against your directory, where the guest object actually exists.

In Okta, don’t edit the built-in Microsoft IdP — create a new OIDC Identity Provider (Security → Identity Providers → Add → OpenID Connect IdP) with the following endpoints, replacing [MS_TENANT_ID] with your tenant GUID:

You’ll also need an App Registration in EntraID (Application type: Web) with:

• The Okta redirect URI (https://<your-okta-domain>/oauth2/v1/authorize/callback) added under Authentication → Redirect URIs.
• A client secret generated under Certificates & secrets.
• The delegated permissions openid, profile, email, and User.Read granted under API permissions.

Understand the guest username format

#

When an external user (e.g. alice@example.com) is invited as a guest into an EntraID tenant, Microsoft does not store their email as the UPN. Instead it generates an internal identifier:

alice_example.com#EXT#@contoso.onmicrosoft.com

This matters because:

• Microsoft’s preferred_username / upn claim will return that mangled string, not alice@example.com.
• If you want Okta to match the user by email, you must map the IdP’s email claim (not sub or upn) to Okta’s username/email attribute in the IdP profile mapping.
• JIT provisioning rules, group rules, and policy conditions should be written against the email claim too, otherwise you’ll end up with users whose Okta username looks like alice_example.com#ext#@contoso.onmicrosoft.com.

Use case: when you need to record a video or share an application via Zoom, and you need the right aspect ratio (i.e. 16:9)

Sample Apple Script for Arc (you can change the app name for other applications):

set appName to "Arc"
tell application "System Events"
    set appProcess to first process whose name is appName
    tell appProcess
        set frontWindow to first window
        set newWindowSize to {1920, 1080}
        set position of frontWindow to {0, 0}
        set size of frontWindow to newWindowSize
    end tell
end tell

If you use a dual (or more) monitor setup, you have to play a bit with set position of frontWindow in order to place the window in the right position. The first value can be the resolution of the 1st monitor (i.e. 1513 for a 14” MacBook Pro), and the second value depends on the resolution of the 2nd monitor. Try some value until you find the right one winking face

set appName to "Arc"
tell application "System Events"
    set appProcess to first process whose name is appName
    tell appProcess
        set frontWindow to first window
        set newWindowSize to {1920, 1080}
        set position of frontWindow to {1513, -1000}
        set size of frontWindow to newWindowSize
    end tell
end tell

Notes:

#

1. In order to work, the Script Editor must be on the same virtual monitor as the application.

2. if you want, you can export the script in .app format and run it without opening the Script Editor

3. I’m not an Apple Script expert. Maybe there is a better way… this just runs fine for my needs slightly smiling face

I had a customer with very specific requirements for MFA:

• No app to be installed on employees’ devices
• No SMS (they cannot use the employees’ personal number)
• Protect with MFA access to a corporate app
• Hardware keys are to be avoided due to the cost and risk of losing them
• Shared PC - included Windows user (more employees use the same session on Windows and share the same password)

Though is not the best in terms of security, it’s very hard for them to change this behaviour.

So, I was looking for a solution to propose. We cannot rely on FastPass because the Windows user is shared. We cannot use SMS, FIDO2 Keys, or other system.

There are a lot of MFA software compatible with TOTP or Google Authenticator, but most of them run without a password or with a master password, making it impossible to use them securely in a shared Windows session.

WinAuth

#

WinAuth is a portable, open-source Authenticator for Windows that provides counter or time-based RFC 6238 authenticators and common implementations, such as the Google Authenticator.

One of the feature is the possibility to protect each Authenticator with a different password. This permit to run the app on a shared PC.

You can download it from Github GitHub source code: (https://github.com/winauth/winauth)

Demo

#

Advantages of WinAuth

#

• Light (~5Mb)
• Don’t require installation and run without admin permissions
• Support multiple MFA and permit to protect each one with a separate code
• It’s open source. A customer can potentially customize it, remove unnecessary features, add custom branding, etc.

Warning

#

All that glitters is not gold :winking-face: there are some caveats to consider:

• The app is not maintained anymore. Last release was in 2017, that means that it can have issues with newer version of Windows, unfixed security bugs, etc
• Though it is possible to have separate passwords, every user can delete every Authenticator
• You have to educate users on how to add a new Authenticator and protect it with a password
• It’s a good starting point, but to use it in an Enterprise context, the application must be customized by the customer.

Alternatives to be evaluated

#

• https://github.com/Bubka/2FAuth
• https://saaspass.com/
• https://github.com/2fast-team/2fast
• https://github.com/multiOTP/multiotp
• https://github.com/VladimirAkopyan/Authenticator