Support for PKCE to prevent `code` injection attacks

[ThisIsMissEm]

PKCE or Proof Key for Code Exchange helps secure OAuth codes during the Authorization Code Grant Flow, this specification was originally written with Public Clients in mind instead of confidential clients, however, in recent years it has become known that PKCE can also help mitigate authorization code injection attacks against resource servers and authorization servers, and is now being recommended as a best practice: https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-27.html#name-authorization-code-injectio

Implementing PKCE is relatively straight forwards:

1. The client generates a code_verifier, a random string using the character set [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", with a minimum length of 43 and a maximum length of 128; The client stores this code_verifier in some place it can read following the redirect to the oauth redirect URL.
2. The client generates a code_challenge using the code_verifier, the algorithm is of S256 uses the following construction: BASE64URL-ENCODE(SHA256(ASCII(code_verifier))), typically S256 is used, but plain is supported as well, in which case the code_verifier and code_challenge are the same (insecure)
3. The client adds the code_challenge and code_challenge_method as parameters to the authorization endpoint redirect URL.
4. The user performs login, and is redirected back with a authorization code
5. The client exchanges the authorization code, but when it does so, it adds the parameter code_verifier which is the code verifier value from step 1, retrieved from storage.
6. The authorization server checks the access grant's code_challenge against the exchanged code_verifier using the stored code_challenge_method to compare (so the authorization server repeats the steps from 2 but with the code_verifier supplied along with the code to the token endpoint
7. If they match, you get back an access token, if they don't you get an error response.

PKCE would be really good to see supported in this package given the simplicity of implementation and the additional security it provides to the authorization code when exchanging it for an access token.

It can also be easily enabled or disabled: simply don't generate the code verifier or do.

The "storage" mentioned above for the code_verifier is typically in the server-side session cookie, much like what's done for the state parameter.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[RomainLanz]

Keep open