Entra External ID custom identity sign in with login_hint results in AADSTS165000 Token was not provided

Both behaviors are explained by how Microsoft Entra External ID handles hints and custom OIDC IdPs; they are current product limitations/behaviors rather than something that can be fixed purely in app code.

1. AADSTS165000 when using login_hint

For MSAL.js, login_hint is designed to hint a specific user account to Microsoft Entra ID so that:

• the correct existing session can be found, and
• the account picker can be bypassed.

For browser apps, this is normally used as described in the MSAL.js SSO guidance:

• Pass loginHint (email/UPN) to ssoSilent or interactive requests so Entra ID can preselect the right account and reuse the session cookie.
• The hint is taken from the ID token (upn or username) and passed between apps to enable SSO.

In External ID (CIAM) with a custom OIDC IdP, the sign-in flow is more complex because the user flow itself must maintain a set of form fields, cookies, and headers across the entire journey (including the redirect to the external IdP and back). The AADSTS165000 error:

"The request did not include the required tokens for the user context... The request did not return all of the form fields. Failure Reasons:[Token was not provided;]"

indicates that when login_hint is added, the CIAM user flow is not receiving all the expected context tokens back. This matches the known issue you referenced: using login_hint together with federated IdPs in External ID can break the user flow’s internal state and result in AADSTS165000.

From the available guidance, the supported pattern for SSO with MSAL.js is:

• Use login_hint, sid, or account as hints to Entra ID for account selection and silent SSO between apps.
• For External ID with federated IdPs, the recommended hinting mechanism for routing to a specific IdP is domain_hint, not login_hint.

Given that:

• login_hint is not documented as a supported way to force a particular external IdP in External ID user flows, and
• there is a known issue where login_hint + federated IdP can cause AADSTS165000,

this scenario is currently a product limitation. The workaround is to:

• Avoid using login_hint to drive IdP selection in External ID user flows.
• Use domain_hint for IdP routing, and use login_hint only in standard MSAL.js SSO scenarios where the user is authenticated directly by Entra ID (not via a CIAM user flow with a custom IdP).

2. Unexpected redirect to okta.okta.com when using domain_hint

For External ID with federated IdPs, domain_hint is the supported way to send users directly to a specific IdP:

• For social IdPs: domain_hint=facebook, google, apple.
• For custom OIDC IdPs: domain_hint=<issuer URI domain>, e.g. "www.linkedin.com".
• For custom OIDC backed by another Entra tenant: domain_hint=contoso.onmicrosoft.com.

In your case, the correct pattern is:

• Configure the custom OIDC IdP in External ID with the Auth0 Issuer URI.
• Use the domain part of the Issuer URI as the domain_hint value.

The behavior you observed:

• Using the Issuer URI with a trailing slash in the IdP configuration causes the user flow to redirect to okta.okta.com/app/office365.
• Removing the trailing slash in the Issuer configuration makes the user flow work correctly.

This matches the documented requirement that for custom OIDC IdPs, the domain_hint must be the domain segment of the Issuer URI, and the configuration must be consistent. A trailing slash in the Issuer can cause incorrect parsing or matching of the issuer/domain, which in turn can route the request to an unexpected IdP (in your case, an Okta Office 365 app) if that issuer/domain pattern matches some internal federation configuration.

So for stable behavior:

• Ensure the custom OIDC IdP Issuer URI in External ID does not include an extra trailing slash if that breaks the user flow.
• Use the domain portion of that Issuer URI (without protocol and without trailing slash) as the domain_hint value.

3. Practical guidance for your scenario (custom “Sign in with SSO” button)

Given the current behavior:

• To implement a custom “Sign in with SSO” button that:
  • collects the user’s email,
  • determines whether the domain is federated,
  • and then routes to the correct IdP,
  use this pattern:
  1. Look up the user’s email domain in your own app logic.
  2. If it maps to your Auth0-based custom OIDC IdP, call MSAL with a request that includes the appropriate domain_hint (the domain part of the Auth0 Issuer URI), not login_hint, to drive home realm discovery.
  3. Let the External ID user flow handle the redirect to Auth0 and back.
• Use login_hint only for standard MSAL.js SSO scenarios where the user is authenticated directly by Entra ID and you are not traversing an External ID user flow with a federated IdP.

If the AADSTS165000 behavior with login_hint in External ID + custom OIDC is blocking a required scenario, the next step is to treat it as a product bug/limitation and open a support case, referencing the known issue and the error code, so it can be tracked and addressed by the product team.

References:

• Single sign-on with MSAL.js
• Identity providers for external tenants
• Tutorial: Add federated identity provider sign-in and sign-up web flow to your iOS app
• Tutorial: Add federated identity provider sign-in and sign-up web flow to your Android app
• Microsoft Entra External ID frequently asked questions