Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An option to require PKCE parameters #179

Open
saschanaz opened this issue Mar 19, 2023 · 6 comments
Open

An option to require PKCE parameters #179

saschanaz opened this issue Mar 19, 2023 · 6 comments
Assignees
Labels
compliance 📜 OAuth 2.0 standard compliance documentation 📑 Improvements or additions to documentation security ❗ Address a security issue

Comments

@saschanaz
Copy link
Contributor

It seems it's fully optional right now:

// optional: PKCE code challenge
if (code.codeChallenge) {
if (!request.body.code_verifier) {
throw new InvalidGrantError('Missing parameter: `code_verifier`');
}
const hash = pkce.getHashForCodeChallenge({
method: code.codeChallengeMethod,
verifier: request.body.code_verifier
});
if (!hash) {
// notice that we assume that codeChallengeMethod is already
// checked at an earlier stage when being read from
// request.body.code_challenge_method
throw new ServerError('Server error: `getAuthorizationCode()` did not return a valid `codeChallengeMethod` property');
}
if (code.codeChallenge !== hash) {
throw new InvalidGrantError('Invalid grant: code verifier is invalid');
}
}

Could be great if there's an option to force it. Of course one can block the request manually by checking the query, though.

@jankapunkt jankapunkt added the compliance 📜 OAuth 2.0 standard compliance label May 30, 2023
@jankapunkt
Copy link
Member

I have to read it up again, but I think to remember the standard does not define whether this is to be enforced, which is why it's optional in the first place and considered an implementation detail. However, I will check again and come back to you.

@saschanaz
Copy link
Contributor Author

saschanaz commented May 30, 2023

Note that there's a relevant attack described in OAuth 2.0 Security Best Current Practice:

4.8. PKCE Downgrade Attack

An authorization server that supports PKCE but does not make its use mandatory for all flows can be susceptible to a PKCE downgrade attack.

@jankapunkt
Copy link
Member

@saschanaz I'm definitely with you on this topic, however I need to review the tests and code to see, what is already implemented. It mostly breaks down to this:

This fact can be used to mitigate this attack. [RFC7636] already mandates that

  • an AS that supports PKCE MUST check whether a code challenge is contained in the authorization request and bind this information to the code that is issued; and

  • when a code arrives at the token endpoint, and there was a code_challenge in the authorization request for which this code was issued, there must be a valid code_verifier in the token request.

Beyond this, to prevent PKCE downgrade attacks, the AS MUST ensure that if there was no code_challenge in the authorization request, a request to the token endpoint containing a code_verifier is rejected.
Note: ASs that mandate the use of PKCE in general or for particular clients implicitly implement this security measure.

Would you support us with a review if we provide a PR? Can you test against a real-world setup?

@jankapunkt jankapunkt added the security ❗ Address a security issue label May 30, 2023
@saschanaz
Copy link
Contributor Author

Would you support us with a review if we provide a PR? Can you test against a real-world setup?

I can review to see if it fits what the spec says, but I don't have a real-world setup now since I still haven't figured out how to implement #180.

@jankapunkt jankapunkt self-assigned this Oct 26, 2023
@jankapunkt
Copy link
Member

FYI and FWIW;

While I'm actively working on a solution to force PKCE for all clients I wanted to underline, there is a current way to enforce PKCE for all clients via model implementation in model.saveAuthorizationCode.

The last two parameters of saveAuthorizationCode are codeChallenge and codeChallengeMethod. By throwing an error in absence of codeChallenge you can avoid issueing the access token in the first place, which baically implements the above described mitigation.

@jankapunkt jankapunkt added the documentation 📑 Improvements or additions to documentation label May 13, 2024
@jankapunkt
Copy link
Member

self note: add this to the docs then we can close this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compliance 📜 OAuth 2.0 standard compliance documentation 📑 Improvements or additions to documentation security ❗ Address a security issue
Projects
None yet
Development

No branches or pull requests

2 participants