Using Microsoft IdP via OIDC, allowing any issuer

Help
, ,
1

Hi folks! I’m looking for a way to allow any users with a Microsoft account (so either consumer accounts, or an account on any Azure AD instance) to log in. I don’t want to have to do actual AD integrations with all of our customers who use it, since we’re dealing with government organizations and the like and that’d just never get done.

I’ve already tried two different approaches. One was the “vanilla” Microsoft connector, which wouldn’t cut it since it only works for “consumer” Microsoft accounts as far as I can tell.

My other approach was a custom OIDC connector (with config values as in this MS doc, with the common tenant value). The problem is that if I use the common tenant in my configs (so use URLs that look like https://login.microsoftonline.com/common/...), the issuer of the ID token will be either the “consumer” tenant or the tenant ID of an Azure AD. So while the OIDC connector nominally works, I’d have to set up a separate connector with different issuer configs for each of our customers’ Azure AD tenants, which is pretty clunky.

If I was doing this “manually”, I’d just check that the issuer starts with a https://login.microsoftonline.com/ and call it a day, since we don’t really care who the specific issuer is.

Any workarounds or suggestions?

1 Like
2

We’re trying to do the same thing and would like to know how to achieve this.

When trying to set up the OIDC connection using Microsoft’s common URL it fails because their issuer URL has {tenantid} in it which fails to be classified as a proper URL.

From their [documentation page|OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft Entra | Microsoft Learn] you can surmise their global openid-configuration URL is:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

Just like Orbat, we don’t want to restrict to a particular organisation, we just want anybody with a MS account to sign in. Any advice?

3

Has anybody figured this out? It’s weird this is a limitation on Auth0 itself.

4

Hi I’ve been running into this problem recently. It is exceptionally stupid that this still isnt properly solved however there is a workaround using a custom policy instead of a user flow. Follow the top comment to the post below

https://learn.microsoft.com/en-us/answers/questions/91519/azure-b2c-multi-tenant-sso-microsoft-work-or-schoo

"Michael Washington

It is a lot of careful steps and configuration, but, it does work:

To use Custom Policies, the first step is to complete all the steps described here:

Get started with custom policies - Azure AD B2C | Microsoft Learn

Then complete the steps described here:

Set up sign-in for multi-tenant Azure AD by custom policies - Azure AD B2C | Microsoft Learn"

some notes:
Stick with the social provider template even if you dont need facebook, just search and remove anything that references it.

in trustFrameworkBase, under the technical profile for “AAD-UserReadUsingAlternativeSecurityId” set the input claim to required = “false”. im pretty sure this is something to do with facebook as well.

good luck!