External ID – Microsoft Account (LiveID) Custom OIDC Provider Not Selected During Username Discovery

Abhiram Mangde 180 Reputation points
2026-07-22T07:23:22.4833333+00:00

Hello Microsoft Support Team,

I am experiencing an issue with Microsoft Account (MSA / LiveID) authentication in an External ID tenant and would like assistance understanding whether the current behavior is expected.

Environment

  • External ID Tenant
  • Authentication flow:

Application -> Keycloak -> External ID (ciamlogin) -> Identity Provider

We are not using External ID User Flows. Authentication is initiated directly through the External ID authorization endpoint and brokered through Keycloak.

Working Scenario (Google)

Google is configured under:

External Identities

→ All Identity Providers

→ Google

When a Google user enters their email address, the GetCredentialType response contains:

{

"IfExistsResult": 0,

"HasExternalOidcFed": true,

"FederationRedirectUrl": "https://accounts.google.com/..."

}

The user is redirected to Google authentication and login succeeds.

Failing Scenario (Microsoft Account / LiveID)

A Microsoft Account user (e.g. ******@outlook.com) enters their email address.

The GetCredentialType response contains:

{

"IfExistsResult": 1

}

No federation information is returned:

"HasExternalOidcFed": true is not present.

No:

"FederationRedirectUrl"is returned.

The user remains on the External ID login page and receives:

"This account does not exist in this organisation. Enter

a different account or <aadSelfSignup>create a new

one</aadSelfSignup>."

No request is ever sent to: login.live.com Therefore the Microsoft Account provider is never invoked.

Configuration Already Implemented

Following Microsoft documentation for Microsoft Account federation:

Observation

The custom OpenID Connect provider exists and is configured successfully, however runtime behavior remains unchanged.

Google federation is discovered automatically during username discovery, but Outlook.com / Live.com users are not associated with the custom OIDC provider.

As a result: GetCredentialType -> IfExistsResult = 1 -> Authentication stops

before federation is attempted.

Question

Can External ID's email-first login experience / Home Realm Discovery (GetCredentialType) automatically route Outlook.com / Live.com users to a Custom OpenID Connect Provider when authentication is initiated directly through:

/oauth2/v2.0/authorize

without using External ID User Flows?

If additional configuration is required to associate the custom OIDC provider with the authentication experience or application, please advise.

I would also appreciate clarification on whether this scenario is supported by design.

Thank you.

Microsoft Security | Microsoft Entra | Microsoft Entra External ID
0 comments
Answer accepted by question author

AI answer

2026-07-22T07:23:57.42+00:00

No. In the provided documentation, custom OIDC identity providers in External ID must be added to a user flow before they are available on sign-in pages. Simply configuring the provider under External Identities > All identity providers does not make it available at runtime.

For Microsoft account federation specifically, the documented setup is:

  1. Configure Microsoft account as a custom OpenID Connect identity provider with:
    • Well-known endpoint: https://login.microsoftonline.com/consumers/v2.0/.well-known/openid-configuration
    • OpenID Issuer URI: https://login.live.com
    • Client authentication: client_secret
    • Scope: openid profile email
    • Response type: code
  2. Add that identity provider to a user flow under: Entra ID > External Identities > User flows > [flow] > Settings > Identity providers
  3. Save the user flow so the provider appears on the sign-in page.

The available context does not document support for automatic email-first discovery or GetCredentialType routing of Outlook.com/Live.com users to a custom OIDC provider when authentication is started directly against /oauth2/v2.0/authorize without using External ID user flows.

The closest documented guidance indicates:

  • a custom OIDC provider not appearing on sign-in is commonly due to it not being added to the user flow,
  • direct routing methods for custom OIDC providers are not a reliable or supported method today,
  • for custom OIDC providers, the supported sign-in experience is tied to user flow configuration.

Supported next step:

  • Use an External ID user flow and add the Microsoft Account custom OIDC provider to that flow.

If the goal is direct runtime selection of a custom OIDC provider based on the entered email address without user flows, that behavior is not described as supported in the provided material.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.