How to Store JWT for Authentication 

I was wondering about that, nice fix!

how would this be implemented in a GraphQL server? All requests would have the same 'scope' and since the cookie is not accessible via JS we cannot selectively add/remove it from requests.

That makes sense. Without this detail CSRF is still possible because an attacker could just hijack and use the refresh token.

I wonder what the benefits would be of this approach versus storing the JWT in a cookie and turning SameSite to Strict mode

@@alexleung842 I don't think an attacker can capture a cookie with a CSRF attack. They can only make the user make unintended requests.

Localstorage is subjected to XSS. So if you can prevent XSS in the first place, then you're ok. If your site is subjected to XSS, then it's somewhat game over i think.

I dont think httponly means same domain. It means javascript cant access it. But javascript can still make a request somewhere and it will automatically be sent with the request. Not sure if im 100% right tho

@@k3vinshum u r correct

any updates on your thoughts about your comment? wondering if u had enough time to look into that deeper

i think you're right @patricknazar, i'm still confusing how to store the token in a public client and protect them from xss and xsrf attacks. do you have any suggestions ?

The refreshToken endpoint returns a new JWT accessToken, just not as a cookie. The JWT that expires is the one being held in a variable, so the server never has to store a state, it just needs to check that the accessToken has not expired.

Oxcorp I’m still not completely getting this. If the refreshToken endpoint returns a new accessToken, why can’t a malicious script/request call the refreshToken endpoint to get a new accessToken and then go to town?

@@benjidaniel5595 There's not really an approach you can take to defend against a full on XSS attack like that which I know of, but a CSRF attack can't perform tasks like this.

Not gonna help. If you have an XSS vulnerability, the attacker will still be able to make requests from your domain. Storing an access token in httpOnly cookie is a way to go.

Yeah I agree with you; The fact is with only the refresh token you can get a new access token. I think the in memory saving part is completely redundant, saving both access and refresh tokens in http only cookie makes more sense specially because we can do another check while validating refresh token. Before validating refresh token we should check if the access token is valid and only expired then we proceed to check the refresh token.

Have you gotten an answer for this question?

@Matthew Caseresthat way, you still have to save the cookie in browser. Saving in memory is more feasible.

not on every request just when the access token expires, so could be every 15 minutes

1. for CSRF the attacker can't read the response of the request and can't get the access token 2. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-M6N7gEZ-IUQ.html

if you put the refresh token in a http only cookie, the idea is the malicious site can't access it they can make you do a request, but they can't read the response to get the access token

@@bawad But why? If an attacker manages to inject JS code into my app, why cant they do a fetch to the /refresh-token endpoint and read the body of the response? What is preventing them? It will look like a same site request like any request you do. Or what am I missing?

I think there might be an exploit without doing any re. Just use a proxy to check the requests that get made, to see how the refresh token is used. Then in the payload do a fetch and get an access token.

@@juliengrijalva8606 I don't think you can just sniff out refresh token from a proxy since HTTPS is encrypted.

@@Yutaro-Yoshii you misunderstood what Julien wrote. You can see what PATH has been called to get the access token, so you "attacker" can call it as well and get the access token.

@@zerefdev Path is also TLS encrypted in https. Though there are some ways to get around this using man in the middle tool like mitmproxy so that might be what he meant. But to get this to work you'd need root write access to trusted CA list on the client so it's not a free pass.

@@Yutaro-Yoshii OP is talking about XSS (why would you need a mitm proxy/tools if you can inject your own js code)

yeah I've come to the conclusion that if your vulnerable to xss, it doesn't matter what you do ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-M6N7gEZ-IUQ.html

That's what I was wondering as well. Props to the channel owner for making and update addressing this flaw.

@@bawad if the attacker knows how this variable is called, they can simply inject js to steal it

You can generate httpOnly cookies which also work on different subdomains. I wouldn't put the backend and frontend on entirely different domains unless you're running serverless, but that introduces other differences as well.

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-GdJ0wFi1Jyo.html

@@bawad This does not give the answer to cross domain i.e. client hosted on one domain and back-end on another domain

What do you recommend in that scenario?

@@bawad I am still looking for a solution to that problem. Do let me know what you think will work! Nice video btw

If the attacker is able to make a request on the users behalf AND read the response, I don't think it matters where you store the access token your in trouble

@@bawad Good point! I'm not sure if I am deep enough in JS, but as far as I know, for XSS it doesn't make a difference whether you make an AJAX request or read a value from local storage, because anyway you just need to execute code in users's browser. So I think the idea with storing the token in memory makes it more complicated to the attacker (and also for the developers), but in case of a successfull XSS it would not improve the security. Or is there something I didn't see?

yeah I'm starting to think if someone successfully executes XSS it doesn't matter what you do

I think it's because with XSS you can't read JS variables (or maybe you don't know which one is the token), but if you put it in localStorage an xss can read from that I think that's a valid way to do it if you want to protect against csrf with a token

This is what I was thinking, even if the name of the variable in memory isn't known to the 'malicious script' it wouldn't be too difficult for it to iterate through the variables looking for an object that even vaguely resembles that of a JWT or the like.. I'm still thinking http only cookie is the way to go for that belt and braces security feel..?

I'm not 100% sure, but I don't think you can just iterate through js variables

@@bawad No I'm not 100% either to be honest, I'll have a look into that for sure. It does feel like something that might be possible even if it were a convoluted way, hackers will go to great lengths to steal sh#t :(

If you can read data using javascript, why wouldn’t that be true with xss

> I still don't understand how the refresh is going to work in your case as access token is lost on refresh of web page. we persist the refresh token in a cookie, so when the user refreshes we can use the refresh token to get an access token > and refresh token is stored in cookie which is prone to hacking. if you use an httponly cookie, the cookie can't be accessed by javascript.

if an attacker can have access to the physical device, there is very little you can do to protect it.

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-25GS0MLT8JU.html

The hacker can only make you make unintended requests, they can not capture your cookie and then get the access token

@@mtosity the hacker cannot make the request, he only can "make" you make unintended requests, in your case, suppose that the hacker can capture the response of the generate_access_token route in the XSS script and send from victim's PC to him, it's still very hard to exploit it because the access token life cycle is often very short

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-25GS0MLT8JU.html

Why?

@@bawad The first tab requests a token, then the second tab requests a new token, invalidating the token in the first tab no?

@@hiradr3857 No, because the access tokens are valid as long as their lifetime, they cannot be revoked, because this requires a centralized token provider and then you can also use normal sessions

@@JonasPrimbs got it. So each tab has it's own token.

How is storing the token in memory vulnerable to xss?

​@@bawad 1- if the token is attached in URL param => simply override the XMLHttpRequest to tamper the details, works on all browsers 2- create a new request to the /refresh_token url and get new valid token, works on all browsers 3- if the variable is global (easily accessible!) 4- angular scopes are easily accessible ... I didn't tried react component variable scopes before

If a hacker can do 1 or 2, does it matter where you store the token?

@@bawad of course not (xss is unwanted js, there no escape of possible harms), preventing the xss is vital, approaches like keeping the tokens in localstorage/indexeddb/memory are just about making it harder not preventing it! so why do we make it harder to develop in comparison keeping it in localstorage? preventing xss in not the answer making xss harder is not enough reason to me with vulnerability to xss keeping the token in cookie isn't important too, the attacker can request any endpoint he wants while the user is online (just preventing later usage of tokens)

@@bawad with attack number 1 the attacker cannot access the headers even if they are set by javascript

Andrew Tatomyr my exact thought 🤔

Asking my self the same thing, i believe you should save the refresh token only in a trusted client.

So this would be the case if you were storing the refreshToken in localStorage. The risk to storing the JWT in a cookie is not that it will get stolen, but that a CSRF attack would cause the user to perform an unwanted action with the authentication in their cookie. By using the method he describes in the video it prevents CSRF attacks from executing authorized attacks since those endpoints would not accept any cookies as an accessToken. There would still be an endpoint for generating accessTokens which would accept the refreshToken cookie for authorization, but CSRF attacks would not be able to make multi-step requests like that to generate an accessToken for their own use.

yep if someone gets your refreshToken or accessToken you're screwed

@@Oxcorp so the CSRF is the clue. that makes sense. tx for pointing me out! however, it's possible to use CSRF to get accessToken, isn't it? you merely have to figure out the refresh endpoint.

I imagine it would work well for mobile apps, but there are probably safer platform-specific storage methods which are safe from general attacks. Native mobile apps aren't really open to most XSS/CSRF attacks.

I'm not 100% sure. I've been using a cookie fine in react native, but it may be better to use secure storage

Just revoke that token by storing it in a store for the length of the expiry in a database. So whenever you receive a refresh request to get a new access token, check your store of revoked tokens, and if the refresh token is there just send a 401 response back.

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-25GS0MLT8JU.html

You can use proxy for that, and later on production/qa/dev servers you definitely would benefit from an API Gateway! Samesite strict for the HTTP only cookie is vital and important.

yeah I came to the same conclusion

What problem are you having with displaying the user's data in the header?

@@bawad all the problem is in ux. At first we need to validate user token or refresh it, then we need to actualise user data, that's two asynchronous tasks (yeah, i know that they may be pretty fast). But our designs mostly not ready for this cases. Our company before mostly making apps with rails only, without client side apps. Previously we used page loader until all needed data would be loaded, but I still looking for more elegant solution.

gotcha, I'll be covering how to fetch that user data soon :)

You have a dangling closing paranthesis in line 1.

Session and local storage can lead to xss attack.

missed the httpOnly part, my bad.

This is the most popular attack method called "Man in the middle". That's why we need an SSL certificate to encrypt the data package to secure the content of the request body.

npm i --save cors

I wanted this, but wasn't sure how since we are storing the refresh token in a cookie. One of the comments recommended "scope the cookie to only the path for requesting a new access token" that should give the desired effect, I'm going to give it a try

It'll be cool to see you handling keycloak

yeah I want to give okta a try

If a hacker ever gets an access token then your in trouble

But essentially if a baddy knows your refresh-token-URL and you're storing your refresh token in a cookie, and the baddy can get you to click on a link, then they could do a CSRF to your refresh-token-url which would pass your cookie (with refresh-token) and return an access-token to the baddy's site (is this correct? I'm asking 'cause I'm not sure).... Update: I've seen your comment below: "they can make you do a request, but they can't read the response to get the access token" ... what is it that prevents the baddy from reading the response? Update, found this: "In fact, due to same origin policy, the attacker can’t even read the response that contains the token."

@@michaelblom_78 I am still confused. If I manage as an attacker to get JavaScript code running on the site, the request to /refresh-token would be from the same origin? And then I could just read the body to obtain the access token or am I missing something?

It really just depends on what sort of security your website/app needs. If you want to be able to blacklist refreshTokens then you need some sort of session storage; you can implement JWT with sessions, it just seems counter-intuitive. For general use, JWTs save a lot of performance and reduce a point of failure (session storage state/database)

@@Oxcorp Storing sessions in a Redis cache is crazy fast and it doesn't come with a lot of the negatives attached to JWTs (like invalidating tokens in case of theft. Good luck finding that out by the way.)

@@Oxcorp If you have a black list, you're still doing a database lookup though. Sure with the access token you get a small window where you don't need to but still. Also shouldn't there be a security standard for all websites regardless of how small or big the site is? I just want users to login safely and not have their sessions highjacked.

@@hdauven8434 You invalidate JWT tokens by blacklisting the refreshTokens like I mentioned.

@@adamtak3128 You have to do a database lookup when generating accessTokens anyways. Also, all of these concerns about XSS/CSRF still apply to session tokens, the difference is that if a JWT is stolen it will also contain the payload which is easily read. The reason there is not a security standard for all websites is because authentication is not handled the same for all websites, it would also be a bit reckless to have all sites use the same methods because it would put them all at risk at the same time whenever a new exploit was discovered.

It's always nice to have a bit of background on common website security techniques. I would recommend you look into XSS protection techniques and specifics such as CSRF tokens which help stop CSRF attacks by using a hidden form value.

I believe it is still safer to store it in a cookie compared to localStorage as it mitigates the risk to the user performing unwanted actions (as opposed to their JWT getting outright stolen). However the approach he's talking about is best for stuff like SPAs where the user will generally not manually refresh the page very often. In regards to initial content delay, the recommended accessToken expiration is something like 5 minutes, so if your user is only manually refreshing the page every few minutes then the impact will remain the same.

tbh I kind of agree with this to some extent also if your vulnerable to xss that's a big problem no matter where you store the token

No not localstorage. just use cookie httponly and dont change the database by default get or post requests and use cors js for only requests from your website and you are good to go. hard to attack with httponly cookie if your server side is well coded

yeah, he can get as many access token as he likes, I didn't get the concept of this implementation

@@paritoshbatish9984 Yeah. I thought he would talk about pairing httpOnly cookie with CSRF token. But no. What he presented doesn't make sense and is still prone to XSS.

​@@AhtshamShabir According to my current understanding (I am quite new to this), 1. httpOnly cookie cannot be accessed via javascript 2. httpOnly cookie is sent with every request to the server So for an XSS attack, they basically have to do a post request like a form submission where only the refresh token is sent which won't do anything as the access token is to be sent for any request from the server. And there will be only one endpoint like "/refresh" where the server accepts the refresh token and returns a new access token. In conclusion, 1. Upon login refresh token is sent which is stored in httpOnly cookie which cannot be accessed by javascript and is always sent with every request. 2. Upon login access token is also sent by the server, which we store in memory. 3. In the access token we store information like expiry date, etc (I still have to see the video on full implementation) which helps us validate the access token. (the access token is not stored in any DB, it evaluated solely based on the info stored on it. See the blog by hasura for detail) 4. For API's, only access token is required. 5. To get new access token there will be only 1 endpoint to do so which validates the refresh token and sends a new access token. Since access token will be short lived for like 2 mins, an attacker only has 2 mins with that token. See the hasura blog for detail: hasura.io/blog/best-practices-of-using-jwt-with-graphql/

Json web token

@@sivananthdiwakar8591 ah hmmmm

is the refresh_token safe if its HttpOnly enabled? How is that happening

Seeing that you know about this, I have a small question. Copying and pasting the token in another browser (incognito mode, for example), allows me to access the app, so, doesn't that mean that a hacker could access your local storage and take the token in order to gain access? How is not unsafe (not rhetorical)?