Authentication in React with JWTs, Access & Refresh Tokens (Complete Tutorial)

VSCode Theme | Font → Material Theme Darker | Menlo, Monaco "monospace"

In this video we will learn how to handle authentication in React with JWTs and access & refresh tokens. We will learn about the mental model of authentication, where to store each type of token, and finally we will look at some React code to see all of this in practice, so that you can take it and apply it to your own applications!

[Dabayare]

You are good n unique as online instructor. Most ppl don't explain the road ahead as you do. They just jump to launching IDEs.

[TomislavKimovski]

The HTTPOnly cookies travel back and forth with every HTTP request and response, just like regular cookies. The only difference is that the browser will not allow the client-side Javascript to access them, which can prevent certain types of attacks.

[artemvolsh]

Instant subscription, clear, on-point, full of useful theory and practical example. 👏

[x-dev-johndoe]

Great video! The implementation looks really interesting. Could you please share the source code for this project? It would be very helpful for those of us trying to learn and follow along. Thanks!

[mohammadkhakhsoor]

this one just awesome, please more video about authentication and authorization + a comprehensive one for axios
thanks a lot
one of the few channels worth subscribing...

[Diamonddrake]

“Refresh token is only on the server” this is nonsense. Http only cookies are not on servers, cookies are for clients. The server checks the cookie that is sent with every request to the server. It’s not living on the server.

Your video quality is great, but this is a fundamental mistake

[AlgoKemal]

Even if an attacker gains access to access token, they can’t do much with it because they don’t know the secret used to sign the JWT. The secret is stored server-side and remains hidden, preventing them from forging or tampering with the token

[regilearn]

Local storage/ session storage /cookies what is the industries recommended ways to store user details and how to use 3 of the ways in react app

[PrashantSingh-xetn]

Hello,
If we are sending the token in authorization header, then they will be visible to everyone anyways. Why should we not store the access token in session/localStorage?

[deepeshpakhare]

Very practical demonstration of the concept! Thanks !

[Dexquestd]

Thanks for this. I'm voting for this same topic with next js app router please 🙏

[ahmednasser]

Great tutorial, but I have one question what if the user refreshes the app before the expiration time if so the token in memory will be undefined so how the server will identify the user in the refresh token call ? as the API request token is undefined even if the user has a valid refresh token?

[arnaldoceballos]

That's great!! Could you upload the source code to your repository?

[djtoon]

So hard to find instructors like you.Can you add part two explaining how you would add RBAC in this implementation for role based authentication and have private routes and a hint on how to handle this with nextjs 14.We need to understand fully this phrase "Roll you own auth" and not becoming dependant on thirdy party libraries.Thank you

[adnandev_]

This was actually very helpful and cleared a lot of ambiguity I had. Thank you very much.

[joeprince]

Hi Codsen, great video! Thanks for all the wonderful content.

One burning question I've had is why the frontend is responsible for calling the refresh token endpoint? Since the backend is the one sending the 403 with the Unauthorized error, couldn't the backend be responsible for intercepting that request in the error handler and trying to hit the refresh endpoint? Obviously the RT would need to be sent with every request and not just on the specific refresh token endpoint if that were the case, so the AT and RT would be sent with every request.

Any guidance/education on why it's not done all from the backend but rather from the frontend? Is it because now the RT has to be sent with every request? Even with that I would think it's secure because it's still stored in an HTTP-only cookie, but is the concern with a bad actor intercepting the cookie from the request?

[mocastello]

once again a very great and well-explained video like always !! a BIG THANKS from berlin 🖤
all respect for your whole effort producing those video tutorials!

[goljivines]

Very nice and concise tutorial.
However, can you answer my question ?.
Should I do authentication myself or use a third party for that ? Also what are the possible vulnerabilities i am exposed to if i do it myself ?

[adusparx]

If you store token in state won't it get deleted on page refresh? Then what would you send to the server. So every time the page is refreshed the user needs to relogin?

[HeinerAngarita]

I understand the concept of saving the access token in memory and why it's more secure to keep it there. However, what I don't understand is how the server knows it's "you" who sent the request for a new access token when the app is refreshed. Is it determined by IP address? By browser? What information is sent from the front end to the backend to verify that the user is the correct one for that refresh token to generate a new access token?

I need to tell the backend developers what they need to implement for the front end to have a correct flow of the tokens. I would greatly appreciate an explanation of this, as I am struggling to understand how to keep the access token in memory. Currently, I have been saving it in session storage.