Security implications

[psibean]

Coupling this repo along with this article. There are a few concerns.

Firstly, in regards to the article, you should note that logging sensitive data, such as an access token, is not okay and specifically mention you are only doing it for demonstration purposes. And that, for logging, people should follow the OWASP Logging Cheatsheet.

Secondly:

addCookieToRes(res, user, twitterOAuthToken.access_token)

The whole point of PKCE is that the access token should not be received by the frontend. If you're using OAuth2 to authenticate on an SPA, you should use session authentication using a secure, signed, http only cookie, with it's name prefixed with __Host- for additional security. Ideally, you use the access token to receive what you need and confirm the user against their session, store any info against their session, and then revoke the tokens immediately. If you need access to the identity providers protected resources again, have the user re-authorize.

Even if you set the access token cookie to be secure and http only you would still then need to introduce adequate CSRF protection. And you have to do that with session authentication anyway.

I can see it's adding a JWT, but even if you follow oauth.coms self encoded JWT example and their base page, they do not use an access token as part of the JWT. The idea is to use the identity claims as the JWT payload, not the access token itself.

Additionally, you should make it extremely clear that a JWT should only be stored in memory, and ideally it should not be stored in either localStorage or sessionStorage.

The idea is, once you've got what you needed through OAuth2 - you've identified who the user is on your system, and you should be using that information to then construct your JWT. If you want to use a JWT specific workflow, then use the OpenID Connect (OIDC) workflow, which provides you an ID JWT in addition to an access token.

OAuth2 is for authorization not authentication. They are two very different problems. The OpenID Connect attempts to use OAuth2 as an authentication solution.

[imoxto]

This issue has been addressed in #2

[psibean]

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 standard.

"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" - it should NEVER be hardcoded, and that should be made extremely clear.

The whole point of PKCE is to provide CSRF protection on the authorization, using the same value each time completely destroys the point. 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.