Okta Sign In Widget in SPA with Azure AD / Entra getting AuthSdkError: Invalid code_challenge_method

I implemented the Okta Sign In Widget in my React App with Okta as the IdP and got that working fine. I want to extend my React App to use other IdPs so I created a Microsoft Entra IdP server. The parameters are a little difficult to match up with the configuration for Okta so I’m taking my best guess because I don’t see a definitive guide out there for using the Sign In Widget with different IdPs.

I’m getting an error when I call:


The error is:

AuthSdkError: Invalid code_challenge_method

I don’t see the actual GET in the network tab so I suspect that the Okta widget is trying to authorize parameters before it makes the actual call and it’s failing but I can’t be sure. Is there a way to get further visibility into what’s causing the error in the Okta Sign In Widget? I have no way of telling if this is a config problem on the Entra side or a Sign In Widget problem.

Note: After additional reading I’m starting to get the impression that the Okta Sign In Widget can’t connect directly to another IdP. It appears that it can only do it via connection to an Okta IdP then that is configured to relay the authentication and do JIT provisioning as a method of converting to Okta. Is this correct, or can the widget connect directly to an external IdP?

That’s correct, the Okta Sign In Widget can only connect to an OIDC application within Okta.

If you want to log users into your React application via an embedded login widget, they can authenticate through their IdP, but the routing to that IdP will be handled by Okta, based upon the Routing Rules configured in your org.

So the only way to do allow different IdPs without using Okta as a proxy would be to abandon the Okta Sign in Widget and use javascript directly to connect to the different providers?

Are you looking to support multiple Identity Providers within your application, not in your Okta org?

Yes, I want to support multiple IdPs directly from my application. So I’d install my application at my customer site, they would tell me what IdP they want to use and I’d do a little configuration to make my application talk to the correct IdP. There’s no way my customers would agree to pay for multiple IdPs just to use Okta as a proxy.

Unfortunately, I went down the Okta Sign In Widget path months ago because my initial reading brought me to a page that showed what providers the widget could support. I made the mistake of not reading deeply enough to figure out that it was by proxy only.

Ah, yeah, I think you’ll need to manage supporting multiple identity providers from your application side, that way it can redirect users to the appropriate IdP instead of going through Okta.