Share via

Okta as OIDC based external identity provider in Microsoft Entra External ID: provider not appearing on login screen

Anuj Sharma 0 Reputation points
2026-05-03T09:59:03.9866667+00:00

Environment / context

  • Microsoft Entra External ID (External ID) as the CIAM provider for our tenant
  • Okta configured as an OpenID Connect (OIDC) external identity provider in the External ID tenant
  • Created an External ID user flow and added Okta as a custom OIDC IdP
  • Next.js app using NextAuth v4 as the client

What I configured

Okta side:

  • Created an OIDC Web Application in Okta Admin Console
  • Grant type: Authorization Code
  • Added the following redirect/callback URLs to the Okta app:

https://<mytenant>.ciamlogin.com/<tenantId>/federation/oauth2

https://<mytenant>.ciamlogin.com/<mytenant>.onmicrosoft.com/federation/oauth2

https://<mytenant>.ciamlogin.com/<tenantId>/oauth2/v2.0/authresp

https://<mytenant>.ciamlogin.com/<mytenant>.onmicrosoft.com/oauth2/authresp

Entra External ID side:

  • External Identities → All identity providers → New OpenID Connect provider
  • Filled in:
    • Metadata URL: https://<okta-domain>.okta.com/oauth2/default/.well-known/openid-configuration
    • Client ID: Okta app client ID
    • Client Secret: Okta app client secret
    • Scope: openid profile email
    • Response type: code
    • Response mode: form_post
  • User flow type: Sign up and sign in
  • Added the Okta OIDC provider to the user flow under Identity providers

Expected result

Okta should appear as a sign-in option on the External ID hosted login screen, the same way Google and Entra ID do when configured as OIDC providers.

Actual result

The Okta OIDC provider does not appear on the login screen presented by the External ID user flow, despite being configured under All identity providers and added to the user flow.

Notably, the following combinations are working in the same tenant and user flow:

  • ✅ Google as OIDC external IdP — appears and works correctly
  • ✅ Microsoft Entra ID as OIDC external IdP — appears and works correctly
  • ✅ Okta as SAML-based external IdP — appears and works correctly
  • ❌ Okta as OIDC-based external IdP — does not appear on login screen

This tells me the issue is not with the user flow itself, not with OIDC federation in general, and not with Okta as an IdP in general — it is specific to Okta running over the OIDC path inside External ID.

What I've already tried

  • Verified Okta app has Authorization Code grant type and a valid client secret
  • Added all four redirect URL variants (both tenant ID GUID and onmicrosoft.com domain formats) to the Okta app registration
  • Re-checked metadata URL, client ID, and client secret in the External ID OIDC provider config
  • Confirmed the user flow type is Sign up and sign in (not a legacy B2C flow)
  • Verified response_modes_supported in Okta's discovery document includes form_post ✅
  • Verified Okta's discovery document returns email in claims_supported ✅
  • Tried both Okta custom auth server (/oauth2/default) and org-level issuer — neither makes the provider appear
  • Compared Okta's OIDC discovery document against Google's and Entra's — no obvious disqualifying differences found
  • Reviewed Microsoft docs on custom OIDC IdPs in External ID — configuration matches documented steps
  • Confirmed the Okta SAML IdP works in the same user flow — so the problem is isolated to Okta + OIDC specifically

Questions

  1. Why does the Okta OIDC provider not appear on the External ID login screen despite being configured correctly and added to the user flow?
  2. Is there a known incompatibility between Microsoft Entra External ID's custom OIDC federation and Okta specifically — given that Google and Entra work as OIDC IdPs and Okta itself works as a SAML IdP in the same flow?
  3. Is there something in Okta's OIDC discovery document or token response format that External ID silently rejects, causing the provider to be hidden rather than throwing an explicit error?
  4. Are the redirect/callback URLs above the correct format for Okta → External ID OIDC federation?
Microsoft Security | Microsoft Entra | Microsoft Entra External ID

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-05-03T09:59:17.0166667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The behavior described cannot be fully explained or diagnosed with the available information in the provided context.

    The context confirms the following about Microsoft Entra External ID and custom OIDC providers:

    • External tenants support OpenID Connect and the authorization code flow, including PKCE, as well as other OAuth2/OIDC flows.
    • Custom OIDC identity providers can be configured and then added to user flows so they appear as sign-in options on the hosted page.
    • When adding a Microsoft Entra ID tenant as an OIDC IdP, the IdP is configured under All identity providers and then explicitly added to a user flow so it appears on the sign-in page.
    • The same pattern applies to other OIDC IdPs (for example, Microsoft account or Google): configure the IdP, then add it under Identity providers in the user flow.
    • Claims and attributes from the external IdP are only stored if the corresponding attributes are enabled in the user flow, but this affects what is stored and emitted in tokens, not whether the IdP button appears.

    From the context, the only supported, documented conditions for an OIDC IdP to appear on the External ID login screen are:

    1. The OIDC IdP is successfully created under External Identities → All identity providers.
    2. The OIDC IdP is explicitly added to the specific user flow under User flows → [flow] → Identity providers.

    If both conditions are met, the IdP should appear as a sign-in option. The context does not document any special-case incompatibility or filtering logic for Okta as an OIDC provider, nor any additional hidden requirements (such as specific discovery document fields, specific claim sets, or redirect URL patterns) that would cause the provider to be silently hidden.

    The context also does not provide a normative list of valid redirect/callback URL formats for third‑party OIDC IdPs such as Okta, beyond showing that for apps in external tenants the authority format for MSAL-based applications is https://<tenant-name>.ciamlogin.com/ and that external IdPs are added to user flows as sign-in options.

    Because of this, the following questions cannot be definitively answered from the context:

    1. The specific reason why the Okta OIDC provider does not appear on the External ID login screen in this scenario.
    2. Whether there is a known incompatibility between External ID’s custom OIDC federation and Okta specifically.
    3. Whether any particular field in Okta’s discovery document or token format is causing External ID to hide the provider.
    4. Whether the exact redirect URL patterns listed are correct for Okta → External ID OIDC federation.

    Only the general, documented behavior can be stated:

    • External tenants support custom OIDC IdPs, which must be configured and then added to user flows to appear on the sign-in page.
    • Identity providers (including custom OIDC IdPs) are one of several sign-in options that can be configured and then integrated into a sign-up/sign-in user flow.
    • Claims mapping and user flow attribute configuration control what is stored and emitted, not whether the IdP button appears.

    References:

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.