Discussion on "React, NodeJS and JWT Authentication - the right way!"

Gal Malachi · 2020-09-03T19:21:18.000Z

In this series of posts, we will create a secured end-to-end JWT-based authentication mechanism using NodeJS, Express, PassportJS and React. There's a lot of information online about JWT-based authentication, however, I still see a lot of questions ...

First of all, the post is great, it has helped me a lot. I have it so very close to working. The encryption/decryption appears to be working fine, and it will set the refresh token in the cookie in the response, but that's as far as I can get.

I can't be 100% sure, but I think you may have some typos in the code you posted? I can't seem to get it to work as-is.

For example, in the function generateTokensAndAuthenticateUser(), you have await generateAccessToken(userId) immediately followed by a non-awaited generateRefreshToken(userId).

That doesn't make much sense to me. Are you completely sure that this code actually works when using the code you posted, verbatim?

Another one that I can't seem to get working is the step where you refresh the token by looking at req.cookies... That request object never has a property named 'cookies' for me. It does though, have the cookie set in the headers, under the name 'cookie', so const [tokenName, tokenEncrypted] = req.headers.cookie.split('=') gives me 'refresh_token' and the gibberish contents of the token, respectively.

Another place that I had trouble with concerned the expirations of the tokens. It appears upon signing the token that you are using a value meant to mean expiresIn (a number of sec from now) and when that value appears again, it seems as if you're treating it as an absolute timestamp.

Oh, I should mention, I converted your ts into plain javascript to attempt this. So there's a possibility that I messed that up somehow, but still that doesn't explain the strange little discrepancies I see in the code as posted.

Thank you so much. I don't want to sound like I'm complaining. It looks like this took a lot of work to put together, and I've definitely learned a lot from it.

Btw, others have mentioned, do you have this on github anywhere? It would make this whole process 100x easier.

Well written Gal Malachi

please provide a full code it more like we have to make a guess everytime we write line

Hi Gal Malachi. Great blog. It is very useful and to the point article. Can you please share the source code? That would be great.

sorry could you give all the code? because it's not everything is clear, but I would like to figure out)

Great post! Until now I used to save the access token in the local storage with expiration of 30 minutes or similar short term. On every full reload of the app or 5 min before access token's expiration - refresh using the refresh token. Is this in fact a bad practice? should I persist the access token in the session storage instead?

Hi Eliran Shem Tov,

Thanks for the feedback! Yes, it’s considered as a bad practice. You shouldn’t store the token in local/session storage. In part 2 of the series I deal with the client side, and provide code examples, I believe you’ll find some useful information there!

Gal Malachi wow! what a great lesson... thanks!

This is invaluable information, Thank you so much!

I’m glad that you find it useful, Akash Raju M!

Hey Gal thank you for this amazing thread ive learn alot. However i have some questions:

How JWT in memory protects against XSS attacks as if XSS attack occurs an attacker can access all the resources a client has.
On a "refresh-token" call i saw you are creating both refresh token and an access token, this can eventually increase the login expiration time to indefinitely as we call "refresh_token" before the access token expires and the access token should have short expiry time.
In case of a common server <-> client communication (not micro services) i dont see the reason why to encrypt the access_token. You should not read the jwt payload on the client side?

Hi Lihai Ben-Haim,

Glad you like it! Let me answer your questions:

You are right, it is still not bulletproof, however, it makes it much difficult to still the token from the memory, as the attack should be tailored to your exact app. Combining that with a short-living tokens makes the risk low, but still exists.
The limit come from the refresh token expiration. When the user is active and logged in, we don't want revoke his access. If we want to limit the time for an active user, we can add a logic on the client side or the backend to force logout after a certain period. I didn’t took care of it here, but it is completely possible.
encrypting the token is a good practice as it contains the identifier of the user inside it, and if stolen can give the hacker data that might be used in future attacks.

waiting for next part :)

Thanks for the feedback Tal!

Well done! Very interesting read ✌🏻

thanks, Nimrod, appreciate it.

Discussion

React, NodeJS and JWT Authentication - the right way!

Responses(12)

Recent in Forum

Search Hashnode

React, NodeJS and JWT Authentication - the right way!

Responses(12)

Recent in Forum