Open ThisIsMissEm opened 6 months ago
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.
Keep open
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.
Keep open.
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.
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:
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.code_challenge
using thecode_verifier
, the algorithm is ofS256
uses the following construction:BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
, typicallyS256
is used, butplain
is supported as well, in which case thecode_verifier
andcode_challenge
are the same (insecure)code_challenge
andcode_challenge_method
as parameters to the authorization endpoint redirect URL.code_verifier
which is the code verifier value from step 1, retrieved from storage.code_challenge
against the exchangedcode_verifier
using the storedcode_challenge_method
to compare (so the authorization server repeats the steps from 2 but with thecode_verifier
supplied along with thecode
to the token endpointPKCE 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.