domain_hint with an Okta issuer host is intercepted by home-realm discovery instead of selecting the custom OIDC provider (External ID external tenant)

Question

domain_hint with an Okta issuer host is intercepted by home-realm discovery instead of selecting the custom OIDC provider (External ID external tenant)

Chintan Sukhadiya 0

We have a Microsoft Entra External ID external tenant with a self-service sign-up user flow containing a single custom OpenID Connect identity provider that federates to an Okta org

Issuer: https://<org>.okta.com
Well-known endpoint: https://<org>.okta.com/.well-known/openid-configuration
The provider works correctly when the user clicks its button on the sign-in page.

For custom OIDC providers whose issuer is login.microsoftonline.com, we can skip the sign-in page by sending domain_hint=login.microsoftonline.com (issuer-host acceleration). We want the equivalent behavior for the Okta provider.

Problem: sending domain_hint=<org>.okta.com on the /oauth2/v2.0/authorize request never reaches the custom OIDC provider. Instead, the request is captured by Microsoft home-realm discovery: because <org>.okta.com happens to resolve as a federated Microsoft 365 domain, the response is a 302 to a WS-Fed endpoint (.../app/office365/.../sso/wsfed/passive?...wtrealm=urn:federation:MicrosoftOnline) a completely different federation path than the OIDC provider configured in the tenant, and one that cannot complete our sign-in.

So for Okta-issued providers there appears to be no domain_hint value that selects the configured custom OIDC identity provider — Microsoft-domain values accelerate to the wrong realm, and non-Microsoft values are either intercepted (as above) or ignored.

Question: for a custom OIDC identity provider whose issuer is an Okta org URL, is there any supported domain_hint value (or other authorize-request parameter) that routes the user directly to that provider, skipping the sign-in page? Or is the sign-in page unavoidable for non-Microsoft OIDC issuers in external tenants today?

Related question about the general domain-routing scenario: https://learn.microsoft.com/en-us/answers/questions/5964766/how-to-route-users-directly-to-a-custom-oidc-ident

0 comments

1 answer

Your answer

Answer 1

Update after further testing (Sep 2026):

Some additional findings that narrow this down:

login_hint works - but only for existing accounts. If the email passed in login_hint belongs to a user whose account in the external tenant was created via the custom OIDC provider, home realm discovery resolves the account to its owning IdP and redirects straight to Okta with no identifier page and no IdP button click. This works on any browser/device (it's a directory lookup, not cookie-based), so returning users get a fully transparent SSO experience.
The gap is therefore only the first-ever sign-in per user. For an email that doesn't yet exist in the tenant, there appears to be no way to route to the custom OIDC provider: domain_hint is intercepted as described above, and the undocumented idp= parameter (tried with both the identity provider GUID and the issuer URI) is silently ignored. The user must click the "Sign in with <provider>" button once; after the federated account is created, login_hint handles all subsequent sign-ins.
For completeness: the sign-up path can't bridge this either - entering an unknown email on an OIDC-only user flow returns "<email> can't be used currently because it's not part of an organization", so identifier-first input never routes to the provider.

Refined ask: is there a supported (or planned) way to accelerate an unknown user directly to a custom OIDC identity provider - e.g., a per-IdP hint value, or domain-based routing for OIDC federation similar to what SAML/WS-Fed direct federation has via its Domains list?