invalid_client when no Client Secret sent for PKCE

[Kyle Bernstein]

It appears to me as though the solution implemented in #1276 is not sufficient.

I still need to send a client_secret with the request as an empty string to generate a token.

For example:

Sending a POST body to the token endpoint with:

grant_type: authorization_code
redirect_uri: http://localhost:5173/auth/callback
code: vhwvvKaxY06hU4aMrOPsXdwBtF08Ir
code_verifier: bc98e9d90140488b90947818e2409752ae2c945fd3c3446797c36fdc69da52c155a474dce9b74b02a5a50c7dd7339414
client_id: UkJBa4KTx9hff93Nkk2nuLALZWPV5AkYcyWlsHoQ

Results in an error of {"error": "invalid_client"}

Whereas a body of:

grant_type: authorization_code
redirect_uri: http://localhost:5173/auth/callback
code: vhwvvKaxY06hU4aMrOPsXdwBtF08Ir
code_verifier: bc98e9d90140488b90947818e2409752ae2c945fd3c3446797c36fdc69da52c155a474dce9b74b02a5a50c7dd7339414
client_id: UkJBa4KTx9hff93Nkk2nuLALZWPV5AkYcyWlsHoQ
client_secret:

Works correctly. I should be able to omit the secret entirely (as some frontend OIDC libraries will do) and still have a successful response. Line 173 in oauth2_validators.py which should fix the problem:

getattr(request, "client_secret", "")

Is still returning None if the secret was not sent at all as None is the value set in the request object, so the default empty string never gets set.

I have verified I am running version 2.3.0 which appears to be the latest release.

[pablo]

Just to confirm that this breaks the standard I reviewed the OAuth2 documentation. It says in section 3.2 that:
"Parameters sent without a value MUST be treated as if they were omitted from the request."
So not sending the parameter, or putting in a null/empty value should be treated the same. Even though it is not completely clear what they mean with 'without a value'.

https://datatracker.ietf.org/doc/html/rfc6749#section-3.2

This is confirmed in section 2.3.1 where it mentions the client_secret parameter MAY be omitted by clients if empty.
https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1