How do I configure an OIDC Enterprise Connection to use Authorization Code flow with PKCE?

Continuing the discussion from OIDC enterprise connection to Azure AD using authorisation code flow with pkce:

Hi Dan, it looks like this feature was being actively worked on back in 2023. Is it available now? If so, will you point me in the direction of the documentation please? I found this somewhat related post about using a custom OAuth2 connection, but I have not been able to figure out how to, or whether it’s possible to, create a custom OAuth2 Enterprise connection.

I’m able to create an OIDC enterprise connection, with Front Channel communication, and the metadata specifies that acceptable response_types are code and token, however I see in the redirect to the IdP response_type=id_token. I can’t seem to get it to use code, which is what I would hope to see.

Hi @neal.ferrazzani, and thank you for bringing this up again. I’ll do some research and get back to you.

Thank you Teodor. To clarify though, I am interested in PKCE with an OIDC Enterprise connection, not Azure AD. That was just the closest post I could find. I followed the setup documentation. pkce is set to auto. Communication is set to “Front Channel”. The OIDC metadata specifies response_types_supported as [ "code", "token" ]. But when the user clicks the IdP login button on the Universal Login page, the request to the IdP that I am able to see in the browser tools has response_type=id_token and response_mode=form_post rather than what I would hope to see response_type=code and code_challenge={challenge}.

Thank you for your patience!

I’m happy to let you know that it is now possible to set PKCE for enterprise connections. Please see our docs for a guide on how to do it.

Let me know if I can assist you further!
Teodor.

Teodor, the docs you linked to were the docs I linked to in my most recent post and noted that I already followed.

My bad, I didn’t see your update before sending my reply. I will look more into it. :slight_smile:

1 Like

No problem. Thank you for your continued help. Please let me know if there’s any more information that I can share that would be helpful.

In the spirit of providing as much information as possible, I want to share two things.

The first is that while my customer wants to configure their Enterprise OIDC connection to use Front Channel communication with PKCE, our app is a traditional server-side web app and so our Auth0 client Application is configured as such.

Second random thing to share is that I found the custom OAuth2 post, and I attempted it as a workaround although the directions are scant at best. I ran into two problems. First was that I don’t see an API endpoint for programmatically creating Enterprise Connections, just “regular” connections. So for example, when I attempted to create my connection via POST to api/v2/connections the response was a 400 with "message"=>"show_as_button can be set only for enterprise connections”. Also aside from that I ran into a number of other validation errors because it wanted settings for enable_script_context and scripts properties, which I don’t understand or need in my case. I’d need some help navigating this if its even a possibility.

All that said, I’m still hoping that we’ll be able to use an OIDC Enterprise connection and that you’ll be able to illuminate why I’m not seeing it use PKCE when reaching out to the IdP.

Hi @neal.ferrazzani, and thank you for your patience.

It seems that it is not possible to use PKCE when Communication is set to Front Channel.

Let me know if I can assist you further!
Teodor.

That’s confusing. I understand “front channel“ to mean PKCE, as in there is no client secret exchanged on the back end, and this is why your Self-Serve Enterprise OIDC setup UI doesn’t ask for a client secret when choosing front channel.

My latest understanding of the general problem I am having is that there is a mismatch between trying to use PKCE for the enterprise connection and authorization code flow (with a secret) for my app integration w/ Auth0. The reason this was confusing in the first place is that Auth0 makes a self-service flow available for us to provide our users, and the self-serve UI allows customers to configure themselves however they’d like, so I figured that meant that Enterprise Connection configuration was totally independent of how our platform was configured. But that does not seem to be the case. I’m not sure how are customers are supposed to know how our platform integrates with Auth0 and therefore whether they’re supposed to choose front channel or back channel since we are not able to configure the Self-Serve UI to hide options. :confused: