AADSTS165000 "Token was not provided" when login_hint is sent to a CIAM user flow federating to a custom OpenID Connect IdP

The behavior described (AADSTS165000 when using login_hint with a CIAM user flow that federates to a custom OpenID Connect IdP) is not documented in the provided material as a known limitation or bug, and there is no information about status or ETA for a fix.

From the available documentation, only the following points are supported:

1. login_hint and domain_hint behavior

• login_hint is documented as an optional parameter that can be used to prefill the username/email field on the Microsoft identity platform sign-in page, typically for reauthentication scenarios, by reusing a previously obtained login_hint optional claim.
• domain_hint is documented as an optional parameter that can be used to skip email-based discovery for federated directories and streamline sign-in, especially when tenants are federated through on-premises directories like AD FS.
• The documentation does not state that login_hint or domain_hint are supported as a way to deep-link directly into a specific custom OpenID Connect IdP in Microsoft Entra External ID user flows, nor does it describe any special handling for custom OIDC IdPs in CIAM.

2. Supported way to add and use custom OpenID Connect IdPs in External ID

The documented and supported pattern for custom OpenID Connect federation in Microsoft Entra External ID is:

• Configure the custom OIDC IdP in the external tenant:
  • In the Entra admin center, go to Entra ID → External Identities → All identity providers.
  • On the Custom tab, select Add new → Open ID Connect.
  • Provide:
    • Display name (shown to users on sign-in/sign-up).
    • Well-known endpoint (OIDC discovery URI) that exposes issuer, authorization_endpoint, token_endpoint, token_endpoint_auth_methods_supported, response_types_supported, subject_types_supported, and jwks_uri.
    • OpenID Issuer URI` matching the external IdP’s issuer.
• Add the custom OIDC IdP to a user flow:
  • In the external tenant, go to Entra ID → External Identities → User flows.
  • Open the target sign-up/sign-in user flow.
  • Under Settings → Identity providers, select the OIDC identity provider under Other Identity Providers and save.
• Once added, the IdP appears as a selectable option (tile/button) on the user-flow sign-in page. The documentation only describes this tile-based selection model for custom OIDC IdPs.

There is no documented mechanism in this material to:

• Associate a verified domain with a specific custom OIDC IdP for automatic Home Realm Discovery routing in External ID user flows.
• Hide a custom OIDC IdP from the user-flow page while still using it for domain-based routing.
• Deep-link or accelerate directly to a specific custom OIDC IdP using login_hint, domain_hint, or idp parameters.

3. Error handling and common OIDC federation issues

For custom OIDC federation in External ID, the documented error guidance focuses on:

• Ensuring the external IdP returns required claims such as email (for External ID federation scenarios, the email claim must be present in the token configuration of the upstream Entra app).
• Validating that the issuer URI exactly matches the issuer value in the discovery document, and that authorization, token, and JWKS endpoints are correct and reachable.
• Ensuring required attributes like sub and email are present, otherwise External ID may reject the response with error 40015.

The specific AADSTS165000 “Token was not provided” error on the federation callback is not covered in the provided documentation.

4. Architectural guidance from the available content

From the documentation provided, the supported and recommended patterns for External ID and OIDC are:

• Use OpenID Connect with Authorization Code flow (with PKCE) for web apps and SPAs; implicit and ROPC flows are not supported for OIDC external IdPs in External ID.
• Configure the external tenant and user flows, then add custom OIDC IdPs as selectable identity providers in those user flows.
• For SPAs and web apps, use the standard Microsoft identity platform OIDC parameters (login_hint, domain_hint) as documented for general sign-in optimization, but there is no explicit statement that these parameters can be used to bypass the user-flow IdP selection or to implement domain-based routing to custom OIDC IdPs in External ID.

Given the constraints of the documentation provided:

• There is no documented confirmation that the AADSTS165000 issue with login_hint and custom OIDC federation in External ID is a known limitation or bug, nor any ETA.
• There is no documented, supported way in this material to:
  • Deep-link directly to a specific custom OIDC IdP in a CIAM user flow using login_hint, domain_hint, or idp.
  • Associate verified domains with custom OIDC IdPs for automatic Home Realm Discovery in External ID.
  • Hide custom OIDC IdPs from the user-flow page while still using them for domain-based routing.
• The only supported pattern explicitly documented is tile-based selection of custom OIDC IdPs within user flows.

For the multi-tenant “email → route to organization SSO” scenario, no additional architecture or pattern beyond the standard custom OIDC user-flow configuration is described in the provided context.

References:

• Add OpenID Connect as an external identity provider
• Add a Microsoft Entra ID tenant as an OpenID Connect identity provider
• OpenID Connect on the Microsoft identity platform
• Supported features in workforce and external tenants
• Application types for the Microsoft identity platform