How to Store JWT for Authentication

Learn how you can store your JWT in memory instead of localStorage or a cookie for authentication. This method limits your exposure to CSRF and XSS attacks.

#jwt

Links from video:

​
----
#benawad

[tehbeard]

Sending the refresh token with each API call is completely at odds with the aim of the access/refresh token paradigm where the short lived access token goes out with API requests, and the refresh token is only used to request new access tokens.


The fix is simple; scope the cookie to only the path for requesting a new access token. This keeps all the benefits described of access token in memory, refresh token in cookie, and avoids having the refresh token "hanging around" where it shouldn't be (e.g. API requests that may dump the request to logs, leaking the long lived refresh tokens)

[sathishshaj]

Well done Ben looking forward for video on this concept..

[MrScX]

Great stuff! Looking forward to the implementation video.

[fhxopcd]

Thank you for introducing another usuful concept for authentication. I'll look forward to your actual implementation.

[crnholio]

Many thanks for your informative and humorous videos, Ben, but what exactly is the difference to session cookies with a csrf token? The refresh token reminds me of the session id cookie and the JWT would be the csrf token.

[PinkChineseChives]

I have a question regarding the refresh token, as you mentioned when the attacker got the refresh token in the cookie, the attacker can't get access token then the malicious attack won't happen. But when an authenticated user refreshed the page, the access token is gone as well, right? how can this authenticated user get the access token after refreshing the page? (I believe the user needs to login again after refresh the page?)

[dhavall]

I also found this article interesting. Another thing that this kind of approach only authenticates client side. I show a few websites which generally keep access token in cookies and use a csrf token and that's why if we open 'view source', it also gives you authenticated user details whereas in this article's case, it gets user details client side and looks more secure.

[Mrstealurgrill]

your recipe app is frikin good ben. how long did it take you to make? do you have a lot of traction on it?

[kvinshum]

Great video thanks. Quick question with your solution… would it not be the same storing the refresh token in web storage?

[rdvanaltun]

Access to cookies from JavaScript can be blocked easily so actualy XSS is not an issue. If you blocked, browsers will manage cookies in request and responses. Atacker may can stole cookies in file system using a malware anyway but i think it is not a big case. You don't need to store token in memory, this is just increase the complexibility.

[fxstreamer]

the question is how to receive the two tokens from local storage and cookie at the same time with one http request?

[holthuizenoemoet]

storing info in js doest protect it from XSS or even CTFS. you need policies like SameSite Cookie Attribute.

[oussamasethoum]

how can you store the cookie as an http only in case your frontend and backend are server from different domains ?

[GeordyJames]

Hi Ben, If your site is vulnerable to XSS then an attacker can still easily get your access token from global memory. So is this the right method. I am still confused. More over if you are storing refresh token in http only cookie without a csrf token, you are still vulnerable to csrf attacks as csrf attacks works with http only cookie. Eg session cookies.

[axedyson]

Should I use different keys for signing the refresh_token compared to the access_token??

[rstart]

Why backend doesn't refresh an access token automatically if the user is valid and has a valid refresh token in headers? (which can be done e.g. via middleware)

[TheQuinn]

Storing in memory would still be vulnerable to XSS, however, an attacker would have to reverse engineer your application to find where you store it in memory.

[NexusGamingRadical]

Hey, I'm having trouble understanding how this prtects against XSS. I get why it protects against CSRF. But isn't the access token, althought short lived, still expoable to XSS?

[md.akib]

looking forward for the implementation video

[Giigigi]

I am a noob so I do not really know much about this kinda stuff, but I am very curious how do we know when to send the access token back? You said that the refresh token absolutely does nothing. However, when the user refreshes the page, then the user will send us the refresh token to get the access token? So, both cases, we receive just the refresh token and how do we know when to send the access token back?