twitter-oauth2-blog icon indicating copy to clipboard operation
twitter-oauth2-blog copied to clipboard

Still not PKCE compliant as per RFC-7636

Open psibean opened this issue 1 year ago • 4 comments

This issue has been addressed in #2

That doesn't really fix the problem.

The code verifier should not be a hardcoded value, it's supposed to be unique for each request...

These values are not supposed to be hardcoded at all - they should be generated at runtime as per the PKCE standard RFC-7636 sections 4.1 and 4.2.

"We are hard coding `code_challenge` and `code_verifier` for simplicity. You can randomly generate it."

It's not a "can" it's a "should", hardcoding these values literally means you are not compliant with the PKCE workflow - it should NEVER be hardcoded, and that should be made extremely clear. since this is an educational context, you should educate by explaining why this is a problem, and what people should be doing, and how that solves the problem. Ideally you should explain what PKCE is, how it works, and the problems it solves. Or at least link to other resources that provide that information.

The whole point of PKCE is to provide CSRF protection on the authorization, using the same value each time completely destroys the point. you're making the security PKCE brings completely redundant without explaining so. If you're creating an example for educational purposes, then you should be ensuring you are teaching and recommending best practices, or don't bother at all.

Also, the article hasn't been updated either, which is the main "educational resource" which references the repository. Providing people with resources which are not entirely informative over the security implications is increasingly problematic and is creating a circular influx of these kinds of sources.

We are sending the access token in the cookie for simplicity. For a web application, we should store it somewhere more secure, like a database.

As previously mentioned, ideally you shouldn't be storing it in a database at all (and in some cases, depending on the provider, this may actually be against their terms and conditions). What you should be doing is revoking the token once you're done getting what you want from it. And that's because, OAuth2 is for authorisation, not for authentication. This repo portrays itself for educational purposes, but the lack of explanation, reasoning, and the incorrect information, decreases the reliability and credibility.

psibean avatar Oct 27 '22 02:10 psibean