Should Supabase make PKCE optional for confidential clients in the OAuth server?

[jedsaxon]

I am currently setting up Shopify as a confidential OAuth client for Supabase. After getting everything configured and connected, I found out that Shopify does not supply a code_challenge or code_challenge_method in the /auth/v1/oauth/authorize endpoint.

Here is a snippet from RFC 9700 section 2.1.1):

• Public clients MUST use PKCE [RFC7636] to this end, as motivated in Section 4.5.3.1.
• For confidential clients, the use of PKCE [RFC7636] is RECOMMENDED, as it provides strong protection against misuse and injection of authorization codes as described in Section 4.5.3.1. Also, as a side effect, it prevents CSRF even in the presence of strong attackers as described in Section 4.7.1.
• With additional precautions, described in Section 4.5.3.2, confidential OpenID Connect [OpenID.Core] clients MAY use the nonce parameter and the respective Claim in the ID Token instead.

The last point is what is most important. Because the nonce parameter can be used to prevent the same attack that PKCE solves, the OAuth server should make it optional, and assume that the client is capable of checking the nonce parameter on it's own. This is what I hope Shopify is doing for their default authentication service.

There should be a toggle to enable/disable PKCE flow, purely to make it compatible with other clients that don't support the full PKCE flow yet. Maybe if a user were to enable it, they would be warned that disabling it is insecure, or something along those lines.

I could also be missing a really important detail about how the OAuth server and PKCE works as well, since it is quite a lot to wrap my head around. I am not sure if it is something you can just "turn off" either. Or maybe there are a few more exploits found recently that make the PKCE flow a hard requirement, and I should somehow convince Shopify to implement it themselves.

[Nickalus12]

Yeah, you've hit on a known friction point. The OAuth server implementation currently leans heavily into the OAuth 2.1 draft, which effectively mandates PKCE for all client types. I believe the goal was to simplify the security model by moving away from the "nonce vs PKCE" ambiguity, even though the RFCs allow those alternatives for confidential clients.

A toggle for confidential clients would definitely solve the Shopify compatibility issue. Right now that enforcement is hardcoded in the underlying GoTrue engine, so it's not something you can just switch off in your local config. It's worth raising this as a specific compatibility request in the supabase/auth repo, as the team is usually open to these when there’s a clear use case that standard PKCE doesn't cover yet.

[jedsaxon]

Thanks for the response (and sorry for not responding earlier)! I'll definitely raise it up with them and see what happens.