It's not about cookies or localStorage, it's about how you handle the validation and protecting methods IN YOUR BACKEND SERVER. When using cookies, there's still XSS, man-in-middle, you can't stop them, just slow them down. The more appropriate way to protect your user is stop using stupid packages from npm and try to use an access token with a refresh token, limit the number of refresh tokens per user, save the user's IP, browser information, and try to use the RTR (refresh token rotation) method.
Thank you for this video. I saw these videos (same topic) so often and never understood why it is so important, but your example with the package is so good.
Saying that a httponly cookie is safe and cant be accessed is extremely misleading and dangerous. They can be accessed by XSS and XHR attacks. Setting a cookie to httponly is one part of your multi-layer defense, on its own its not enough, but combined with other layers it helps make your service more secure
Yes but it's easier to mitigate against XSS attacks as you can restrict the cookie through SameSite policy, unlike any JavaScript-accessible storage medium.
I agree; more layers are better, of course. I'm not sure about XSS and XHR attacks being able to access httpOnly cookies, though. I thought the httpOnly attribute was specifically designed to offer protection against XSS/XHR attacks. Can you expand or point to an article/page/docs demonstrating this?
The httpOnly attribute of a cookie is exactly there to prevent XSS attacks, so you can't access it using that one. I haven't seen XHR attacks and looking online right now, I don't seem to find a way to access an httpOnly cookie as well.
@@cdruc The problem is not with XSS specifically (accessing the information directly through JS) but that a script can make a fetch from the website's origin and include the credentials (i.e. HttpOnly cookies). If SameSite is not set to either Lax or Strict, it will include those cookies in the XHR request. By default modern browsers will set the SameSite to Lax if it is not explicitly set to None by the website issuing the cookie. So unless you go out of your way to disable it, your users will be safe (also safe against CSRF attacks).
yeah I don't agree. if your web app is compromised by a rogue package, it is game over. even if you have a http only cookie, yes, they might not be able to steal the token exactly, but they can still make requests to your backend through the client browser. the cookie will be sent automatically, and they will do what they want to do regardless. they just won't have the token at hand, they'll be able to use it. this is common advice but security theater. with cookies you will have to start to worry about CSRF etc as well. so no method is without its drawbacks. you need to have a threat model. if your threat model is "infected scripts in my site" then neither cookies, nor local storage will save you.
An infected script could even load additional javascript that exploits the requests on your page. Do requests to your server and then send the data to another server. If you have untrusted 3rd party scripts on your page nothing will save you. If you do not sanitize user input also anything can happen.
I remember being onboarded on a government project that stored JWTs in localstorage which required logging in using your national ID. It was a hell of a shock it got through code reviews and the eyes of every dev who went through it.
There is another interesting thing that discord does, they store the token in localStorage but: 1. When they load the page the key is deleted from localStorage and loaded in memory 2. When a user leaves the website or closes chrome or the discord app they store it again in localStorage so they can get it on the next load. This mostly works for web applications that don't require opening in new tabs tho, because opening new tabs of your website means it doesn't know the current auth token as it is not in local storage anymore until you close the tab that currently has access to it.
Well, unless you disallow access to any other domain with using Content Security Policy (CSP): For example `Content-Security-Policy: default-src 'self'; connect-src 'self'` there is no way to send data to another domain
CSP does not govern browser extensions, nor does it protect from relay attacks. Though, the latter requires you to have a relay vulnerability in your server implementation.
@@_f0x604 No, CORS is aimed at stoping Cross-site Request Forgery, tricking the browser into sending the cookies to perform actions on Website B while the user browses Website A. CSP prevents exactly what's described in the video, exfiltrating data from a site with malicious scripts that are injected into the site (XSS).
@@trapfethen yes, but browser extensions can inject any code and just read you password as you type. When you have a node app, you also have to make sure that the server cannot send data to a malicious sie.
I see so many articles, like "authentication in React" that says to store it in localStorage. Thanks for making this video, I hope it will reach as many people as possible.
It's important to remember the fulcrum of security. What are you protecting, and who are you protecting it from? Sometimes it's okay to do "bad practices" because the application doesn't require much security. As long as you are consciously making that choice. You need to know the rules before you break the rules.
A long time a go for a very long time this was a good practice. You could also bind the token on a specific IP, so you will be still fine. You could also bind the token with a hardware ID and have another validation mechanism on top of the token match. Everything has it's good and bad side. Even considering the Cookie / Session Auth isn't really sure as you can still steal them with proper tools.
@@unfilledflagthats a good point but still a small edge case. However there are also short lived tokens that could be used with refreshing tokens but this is another hussle and story. So maybe just take the hardware UID to compare if the token is coming from the same device if you really want to make your token a bit more secure.
hash your Auth token with a browser fingerprint and store it, that way you can't spoof it on other computers, there are some libraries that help you do it but its definitely possible with a custom made function.
Browser fingerprinting is not reliable and there are a lot of collisions (especially in browsers like Safari on iOS). Trusting a fingerprint is also the equivalent of trusting the client, which is pretty well known as a bad idea. If an attacker has a financial incentive to target your site, they can easily write custom code to spoof the fingerprint itself, thus circumventing the check.
@@gringo5282 yeah, its a game of cat and mouse, availability and confidentiality are opposites in terms of cybersecurity and my solution was mostly done to dether "casual" hackers trying to get a simple oauth spoofing technique paired with a token expiration timer, i guess the real answer depends on the sensibility of your data and how secure you want it to be without affecting the user too much, 2fa auth on every single transaction like some crypto exchanges do it comes to mind, lol.
Sure, I will use session storage (just kidding). On a serious note, it's worth noting that if you opt for local storage, all tabs end up sharing the same storage space. This means that if you're logged in as a regular user in one tab, and someone else logs in as an admin in another tab, the first tab unexpectedly assumes admin privileges as well. Just something to keep in mind!
Well done video! The flow on information was really easy for me to follow, with examples and proofs. I will be making this change, and letting others know too, thanks.
While not entirely wrong, this video is definitely misleading... By this logic, storing tokens anywhere on the client device is insecure. Now there are definitely limits on both ends, but they really shouldn't be defined by the libraries which are under your control. If this is your concern then I have bad news for you: it's probably not much harder to just steal the credentials while logging in, which is obviously even worse. And that's just the tip of the iceberg probably... The real solution is to vet your libraries properly, which is hard yes, but using a compromised library is dangerous no matter where you store your tokens... Also if you say you should use tokens for mobile apps, then what about compromised libraries in the mobile app? And what about the server, how are you gonna hide things from a malicious library there? All that doesn't mean you shouldn't use cookies for authentication if you can though. There are other benefits to that approach - it is basically what they were made for afterall. It's just that they don't really solve the problem described here...
In a production app yeah sure I agree, but for your average hobby developer not necessarily. Its very easy to mess up or just don't know about CSRF and exploiting a site without a CSRF token is a lot easier than finding an XSS vulnerability in a web app built with any modern frontend framework. Supply chain attacks (or just not being careful and installing random packages) is a real threat and if your app is dealing with actually sensitive data you should invest the time to use a cookie based approach 100% of the time
neither cookies nor localstorage tokens will be safe from malicious code in one of your npm packages the actual solution is to limit the amount of npm packages you install, and not load your app with a bunch of random packages with 10 downloads
In that matter there is no difference between browser side cookie vs local storage, the general best practice is to store it as "HttpOnly" server-side, but I do not see that when client and backend are separately developed.
I prefer cookies but you cannot make random requests with javascript to other domains. This is especially easy to lock down with CSP. Even though those libraries read local storage, it is difficult to get that out. Maybe with a browser extension but not likely to happen.
Cookies are more secure but not 100% safe. if you have an XSS, cookies will not help you much if it's a targeted attack, it won't be as easy as blindly stealing auth tokens from the localStorage but an XSS can still do A LOT.
@@codokit If you have an XSS, CSRF protection won't matter anymore because attacks will happen from the same site and not "cross-site", the attacker can make the user visit, fill & submit forms that already have CSRF tokens with them, he might even be able to silently craft & send XHR requests with CSRF tokens on behalf of the user, any cookies will also be sent automatically with the requests. in other words, if you have an XSS, you are screwed.
I like your sarcasm, but you should devently make some warnings for new devs. Like you said, cookies are automaticly within every request. So also in the once made by mallicus code or xss So cookies are even more of a issue than localstorage. The "HTTP Only" Cookie was once an attempt to make it secure, but you just call fetch in js and the browser puts in the cookie anyways... Leaking it. However, you should always use the "Content-Security-Policy" Headers, this makes sure nothing can make requests to any webserver you did not manualy allow first. Then one of the only issues i can think of would be a XSS making a public post on your webpage (in case this is possible) with your secrets, but you can simply check if a post contains a currently valid secret and in case it does just don´t generate the post or invalidate the token like many apps already do it.
I've often wondered about the security of local storage when using frames as well because the top page and page can use local storage for communication. Will be encrypting data here going forward.
@@aGj2fiebP3ekso7wQpnd1Lhd if you intent to keep an access token there it won't prevent an attacker from using it. they just won't know what is inside which is pointless since those tokens are usually random/encoded json of non critical info
Good Topic. But where to store auth Tokens instead of localstorage? Or do you want to say don't use auth tokens? I don't understand your opinion clearly?
If you're using Laravel as a JSON API for a web application, do not use tokens - use the regular cookie based authentication as described here: laravel.com/docs/10.x/sanctum#how-it-works-spa-authentication If you're using Laravel as a JSON api for a mobile app, use token based authentication as described here: laravel.com/docs/10.x/sanctum#mobile-application-authentication If you have both a web app AND a mobile app use.... both. Use the cookie based auth routes for the web app login, and use the token based login routes for your mobile app. ---- I'm not familiar with quasar, but from the looks of it, I think you can just use cookies
Just don't manage your tokens with javascript at all. Set it on the server side in a cookie with httpOnly flag. It will be added to every request automatically, it will be handled by your backend, but won't be accessible via javascript.
Server should support storing token in secure, readonly cookie. Client should not have access to them. Server sets token in secure httponly cookie in login endpoint and server reads token from that cookie.
there are third party extensions to show network packages. the one i found was ugly and cumbersome but it worked, and it wasn't detected by the website
Hi! right now I have to authenticate my app, and I was thinking about saving the jwt token in the localstorage, but seeing this video I know it's not the right thing to do. The only way I have to use my backend (symfony) is with fetch, I use Axios. How should I do the authentication?
I want to use session cookies, but my frontend and backend are in different docker containers, different ports, and possibly different domains, do you recommend any guide that i can follow to use session cookies?
@@bautistaigarzabal I had the exact same situation and I just went with localstorage. It's fine as long as you know the risks. Remember, even discord uses this method
@@bautistaigarzabal thats fine, you still can exchange cookies between each service, even though they are in different container, port, domain, zone, just set the cors on the server to allow subdomain/domain where you serve your frontend app to allow credentials, then each of requests fired via axios should have withCredentials set to true and you are good to go
Doing it on the server's side can be dangerous too, cause if the server automatically reads the cookie to auth you, then what if someone wants to do csrf on you? And also what if your backend is php and you installed a sketchy library, wouldn't it work cause it's server side or what? Solution: Just install trusted libraries
Sounds like snake oil, if you have XSS then you have already a compromised system. I find local storage more straight forward and I only need to care about XSS not some crazy CSRF or extra security headers.
Very good explaination. But what if a npm package tracks all the requests that I am sending with body header and everything including response. How to be safe from that ?
Man, unfortunatley i dont handle auth for my app, my DB does and it stores them in localStorage, and, in some parts of my code extracting tokens from it is actually used. For example to auth the same user across different domains. Thanks for the video btw.
nice, but how the fuck are you store secure tokens in a server-less application. I mean literally, you only get an SPA without any code running on the server other than sending a static file. every single solution will expose the token in an easily accessible way.
I mean, everything's on a spectrum. Local storage is more vulnerable to compromised JavaScript dependencies then a http only cookie. Of course, depending on how sophisticated the malicious dependency, it could make api calls to your backend while you're visiting the page in your browser, but that would have to be more targeted.
@@qbasic16 The encrypted token will be in localStorage (aka Clinet) but the key to decrypt will be in server. Decrypt it then check if the encrypted token does match.
Meaningless in what sense? As long as the token is valid proof of authentication, the attacker will be able to use it to impersonate the user they stole it from.
@@EpKjelltzer But adding the user ip, and browser or extra info should help mitigate those things, plus a refresh token stored on the server. I mean that's the usual JWT pattern. An attacker could decode it but the token should not be valid from anywhere
This video shattered my trust in circle-providing npm packages.
🤣🤣🤣🤣
We can still use ovals though - just be smarter!
Just use squares and cut of the edges, problem solved.
I mean it must be good if it’s had 1 billy trilly billy downloads
It's not about cookies or localStorage, it's about how you handle the validation and protecting methods IN YOUR BACKEND SERVER. When using cookies, there's still XSS, man-in-middle, you can't stop them, just slow them down. The more appropriate way to protect your user is stop using stupid packages from npm and try to use an access token with a refresh token, limit the number of refresh tokens per user, save the user's IP, browser information, and try to use the RTR (refresh token rotation) method.
Thank you
For sessions, you wouldn't really need to take care of refresh and access token, right? A refresh token in itself is like a session already.
this refresh token hype is so funny xd
Thank you for this video. I saw these videos (same topic) so often and never understood why it is so important, but your example with the package is so good.
Saying that a httponly cookie is safe and cant be accessed is extremely misleading and dangerous. They can be accessed by XSS and XHR attacks. Setting a cookie to httponly is one part of your multi-layer defense, on its own its not enough, but combined with other layers it helps make your service more secure
Yes but it's easier to mitigate against XSS attacks as you can restrict the cookie through SameSite policy, unlike any JavaScript-accessible storage medium.
I agree; more layers are better, of course. I'm not sure about XSS and XHR attacks being able to access httpOnly cookies, though. I thought the httpOnly attribute was specifically designed to offer protection against XSS/XHR attacks. Can you expand or point to an article/page/docs demonstrating this?
The httpOnly attribute of a cookie is exactly there to prevent XSS attacks, so you can't access it using that one. I haven't seen XHR attacks and looking online right now, I don't seem to find a way to access an httpOnly cookie as well.
@@cdruc I never heard of a way to read httpOnly from JS that was not a bug in its implementation. Idk what they are on about.
@@cdruc The problem is not with XSS specifically (accessing the information directly through JS) but that a script can make a fetch from the website's origin and include the credentials (i.e. HttpOnly cookies). If SameSite is not set to either Lax or Strict, it will include those cookies in the XHR request.
By default modern browsers will set the SameSite to Lax if it is not explicitly set to None by the website issuing the cookie. So unless you go out of your way to disable it, your users will be safe (also safe against CSRF attacks).
yeah I don't agree. if your web app is compromised by a rogue package, it is game over. even if you have a http only cookie, yes, they might not be able to steal the token exactly, but they can still make requests to your backend through the client browser. the cookie will be sent automatically, and they will do what they want to do regardless. they just won't have the token at hand, they'll be able to use it. this is common advice but security theater. with cookies you will have to start to worry about CSRF etc as well. so no method is without its drawbacks. you need to have a threat model. if your threat model is "infected scripts in my site" then neither cookies, nor local storage will save you.
An infected script could even load additional javascript that exploits the requests on your page. Do requests to your server and then send the data to another server. If you have untrusted 3rd party scripts on your page nothing will save you. If you do not sanitize user input also anything can happen.
I remember being onboarded on a government project that stored JWTs in localstorage which required logging in using your national ID. It was a hell of a shock it got through code reviews and the eyes of every dev who went through it.
There is another interesting thing that discord does, they store the token in localStorage but:
1. When they load the page the key is deleted from localStorage and loaded in memory
2. When a user leaves the website or closes chrome or the discord app they store it again in localStorage so they can get it on the next load.
This mostly works for web applications that don't require opening in new tabs tho, because opening new tabs of your website means it doesn't know the current auth token as it is not in local storage anymore until you close the tab that currently has access to it.
I knew this was a bad idea from hearing it everywhere, but I never understood how the attacks would work. Thank you so much.
Well, unless you disallow access to any other domain with using Content Security Policy (CSP): For example `Content-Security-Policy: default-src 'self'; connect-src 'self'` there is no way to send data to another domain
Can CORS prevent sending data to another domain name as well?
@@_f0x604Nope. CORS is about _downloading_ data.
CSP does not govern browser extensions, nor does it protect from relay attacks. Though, the latter requires you to have a relay vulnerability in your server implementation.
@@_f0x604 No, CORS is aimed at stoping Cross-site Request Forgery, tricking the browser into sending the cookies to perform actions on Website B while the user browses Website A. CSP prevents exactly what's described in the video, exfiltrating data from a site with malicious scripts that are injected into the site (XSS).
@@trapfethen yes, but browser extensions can inject any code and just read you password as you type. When you have a node app, you also have to make sure that the server cannot send data to a malicious sie.
I see so many articles, like "authentication in React" that says to store it in localStorage. Thanks for making this video, I hope it will reach as many people as possible.
We need ask react-devs about httpOnly cookies on interviews.
this video is very misleading
What you should always do, is read your framework of choice docs. Usually they tell you use local storage is not a good idea.
@@whatskookin6429 Absolutely! When it comes to security, never trust some random tutorials or articles.
@@ieatthighswhy is it misleading, it provides a valid POC attack tho.
It's important to remember the fulcrum of security. What are you protecting, and who are you protecting it from?
Sometimes it's okay to do "bad practices" because the application doesn't require much security. As long as you are consciously making that choice.
You need to know the rules before you break the rules.
A long time a go for a very long time this was a good practice. You could also bind the token on a specific IP, so you will be still fine. You could also bind the token with a hardware ID and have another validation mechanism on top of the token match. Everything has it's good and bad side. Even considering the Cookie / Session Auth isn't really sure as you can still steal them with proper tools.
ITS* good side
"bind to ip"
now you break the site for any mobile user that joins or leaves a wifi network
@@unfilledflagthats a good point but still a small edge case.
However there are also short lived tokens that could be used with refreshing tokens but this is another hussle and story.
So maybe just take the hardware UID to compare if the token is coming from the same device if you really want to make your token a bit more secure.
edit out the spelling mistake you made @@gkiokan
in devtool you can use breakpoint to tick unload, so when closing tab/window, it will prevent that , so you can check the network after
hash your Auth token with a browser fingerprint and store it, that way you can't spoof it on other computers, there are some libraries that help you do it but its definitely possible with a custom made function.
Browser fingerprinting is not reliable and there are a lot of collisions (especially in browsers like Safari on iOS). Trusting a fingerprint is also the equivalent of trusting the client, which is pretty well known as a bad idea. If an attacker has a financial incentive to target your site, they can easily write custom code to spoof the fingerprint itself, thus circumventing the check.
@@gringo5282 yeah, its a game of cat and mouse, availability and confidentiality are opposites in terms of cybersecurity and my solution was mostly done to dether "casual" hackers trying to get a simple oauth spoofing technique paired with a token expiration timer, i guess the real answer depends on the sensibility of your data and how secure you want it to be without affecting the user too much, 2fa auth on every single transaction like some crypto exchanges do it comes to mind, lol.
Well where should i then store it? Cookies can get stolen the same way??
Not HttpOnly cookies. But any malicious JS running on your site can still do a lot of damage. All of these are mitigations.
@@davidwang7489
So what needs to be done?
Sure, I will use session storage (just kidding). On a serious note, it's worth noting that if you opt for local storage, all tabs end up sharing the same storage space. This means that if you're logged in as a regular user in one tab, and someone else logs in as an admin in another tab, the first tab unexpectedly assumes admin privileges as well. Just something to keep in mind!
But your second tab will login as your first user, so the admin can never even login.
@@bartwestenenk6088 true, but if you logout on second tab and then login as admin
The same is true for cookies.
Well done video! The flow on information was really easy for me to follow, with examples and proofs. I will be making this change, and letting others know too, thanks.
I hope this goes viral.
While not entirely wrong, this video is definitely misleading... By this logic, storing tokens anywhere on the client device is insecure. Now there are definitely limits on both ends, but they really shouldn't be defined by the libraries which are under your control. If this is your concern then I have bad news for you: it's probably not much harder to just steal the credentials while logging in, which is obviously even worse. And that's just the tip of the iceberg probably...
The real solution is to vet your libraries properly, which is hard yes, but using a compromised library is dangerous no matter where you store your tokens... Also if you say you should use tokens for mobile apps, then what about compromised libraries in the mobile app? And what about the server, how are you gonna hide things from a malicious library there?
All that doesn't mean you shouldn't use cookies for authentication if you can though. There are other benefits to that approach - it is basically what they were made for afterall. It's just that they don't really solve the problem described here...
Super informative and beautifully demonstrated. Thank you for taking the time to make and share with us!
In a production app yeah sure I agree, but for your average hobby developer not necessarily.
Its very easy to mess up or just don't know about CSRF and exploiting a site without a CSRF token is a lot easier than finding an XSS vulnerability in a web app built with any modern frontend framework. Supply chain attacks (or just not being careful and installing random packages) is a real threat and if your app is dealing with actually sensitive data you should invest the time to use a cookie based approach 100% of the time
So what you're saying is I can safely keep tokens in local storage... if I just tell users to keep the dev tools open 😉
neither cookies nor localstorage tokens will be safe from malicious code in one of your npm packages
the actual solution is to limit the amount of npm packages you install, and not load your app with a bunch of random packages with 10 downloads
In that matter there is no difference between browser side cookie vs local storage, the general best practice is to store it as "HttpOnly" server-side, but I do not see that when client and backend are separately developed.
Well wow, malware will simply steal password from login form then
Exactly. Or just interact with the page on your behalf while serving an absolutely positioned clone of the DOM in front.
Gonna be hard to do so when using something like OAuth
@@unfilledflag whatever, the spy script will be stealing all data from owner computer, yet won't be able to login from somewhere else
I prefer cookies but you cannot make random requests with javascript to other domains. This is especially easy to lock down with CSP. Even though those libraries read local storage, it is difficult to get that out. Maybe with a browser extension but not likely to happen.
I feel like the actual issues here were installing random packages that are not vetted and injection.
Cookies and tokens are compromised when you have xss. In both scenarios you are fucked-up. Soo this doesn't add more secureness into your app.
Wrong, httpOnly cookies can't be accessed through javascript
Cookies are more secure but not 100% safe. if you have an XSS, cookies will not help you much if it's a targeted attack, it won't be as easy as blindly stealing auth tokens from the localStorage but an XSS can still do A LOT.
XSS can do a lot, but it's another topic about CSRF protection.
@@codokit If you have an XSS, CSRF protection won't matter anymore because attacks will happen from the same site and not "cross-site", the attacker can make the user visit, fill & submit forms that already have CSRF tokens with them, he might even be able to silently craft & send XHR requests with CSRF tokens on behalf of the user, any cookies will also be sent automatically with the requests. in other words, if you have an XSS, you are screwed.
@@mmghvadd CORS
DAMN DUDE. The quality of content is just amazing!! an instant sub from me!
Good rule of thumb for beginners. Not going to deny it.
But this is irrelevant for any site with even the most simple of Content Security Policies.
Reverse psychology works, you just earned a sub
What about static frontends without ssr? There is no way to use a httponly cookie because you have to access it from js
I like your sarcasm, but you should devently make some warnings for new devs.
Like you said, cookies are automaticly within every request. So also in the once made by mallicus code or xss
So cookies are even more of a issue than localstorage.
The "HTTP Only" Cookie was once an attempt to make it secure, but you just call fetch in js and the browser puts in the cookie anyways... Leaking it.
However, you should always use the "Content-Security-Policy" Headers, this makes sure nothing can make requests to any webserver you did not manualy allow first.
Then one of the only issues i can think of would be a XSS making a public post on your webpage (in case this is possible) with your secrets, but you can simply check if a post contains a currently valid secret and in case it does just don´t generate the post or invalidate the token like many apps already do it.
Nice video. I think also using CSP (connect-src ) could save you from some of these problems
just create a backend that is REALLY safe, the internet is going on a cookieless path, so local storage is not that bad
Discord be like:Yeah, let's store user token in localstorage!
Now how do you do if the application is decoupled from the backend? :)
I love this, so many who think Linux is safe also just trust all their binaries. This is such a problem.
I've often wondered about the security of local storage when using frames as well because the top page and page can use local storage for communication. Will be encrypting data here going forward.
encrypting localStorage is pointless
@@ieatthighs why?
@@aGj2fiebP3ekso7wQpnd1Lhd if you intent to keep an access token there it won't prevent an attacker from using it. they just won't know what is inside which is pointless since those tokens are usually random/encoded json of non critical info
@@aGj2fiebP3ekso7wQpnd1Lhd I explained but youtube deleted my comment. Thank them
@@aGj2fiebP3ekso7wQpnd1LhdWhere are you going to store the (symmetric) encryption key?
It's pointless.
Thank you kind sir
great video!
0:19 bro predicted the future 😂
Ok, so what am I supposed to use instead? Are cookies and session storage any better?
Good Topic. But where to store auth Tokens instead of localstorage? Or do you want to say don't use auth tokens? I don't understand your opinion clearly?
I want my laravel api in a domain. And my quasar-vue app will consum it. My quasar app is a spa and a cordova app! How to handle this the right way?
store them in a cookie which is httpOnly
If you're using Laravel as a JSON API for a web application, do not use tokens - use the regular cookie based authentication as described here:
laravel.com/docs/10.x/sanctum#how-it-works-spa-authentication
If you're using Laravel as a JSON api for a mobile app, use token based authentication as described here: laravel.com/docs/10.x/sanctum#mobile-application-authentication
If you have both a web app AND a mobile app use.... both.
Use the cookie based auth routes for the web app login, and use the token based login routes for your mobile app.
----
I'm not familiar with quasar, but from the looks of it, I think you can just use cookies
Just don't manage your tokens with javascript at all. Set it on the server side in a cookie with httpOnly flag. It will be added to every request automatically, it will be handled by your backend, but won't be accessible via javascript.
@@bartoszkrawczyk4976 this sounds interesting. Thanks you both! Any resources links where can I see a laravel vue spa example?
set the secure flag on your session cookies too pls
what about sessionStorage?
So what the solution for this problem? with Vue as SPA and Laravel API as backend
Server should support storing token in secure, readonly cookie. Client should not have access to them. Server sets token in secure httponly cookie in login endpoint and server reads token from that cookie.
@@Gornius that's a load of bullshit, readonly cookies are not secure in any way
@@minimovzEt Yeah, you're right. I meant httponly.
there are third party extensions to show network packages. the one i found was ugly and cumbersome but it worked, and it wasn't detected by the website
Great video!
Ok, i am newbie if not in local storage then where ?
Supabase stores the `access_token` and `refresh_token` JWTs in local storage. Is there some reason why this is okay?
Hi! right now I have to authenticate my app, and I was thinking about saving the jwt token in the localstorage, but seeing this video I know it's not the right thing to do.
The only way I have to use my backend (symfony) is with fetch, I use Axios.
How should I do the authentication?
If you don't want to go with session cookies localStorage is fine
I want to use session cookies, but my frontend and backend are in different docker containers, different ports, and possibly different domains, do you recommend any guide that i can follow to use session cookies?
@@bautistaigarzabal I had the exact same situation and I just went with localstorage. It's fine as long as you know the risks. Remember, even discord uses this method
@@bautistaigarzabal looks like youtube keeps deleting my responses
@@bautistaigarzabal thats fine, you still can exchange cookies between each service, even though they are in different container, port, domain, zone, just set the cors on the server to allow subdomain/domain where you serve your frontend app to allow credentials, then each of requests fired via axios should have withCredentials set to true and you are good to go
so how to handle tokens if you are not laravel developer? Im using session cookie, and take jwt from it. Is it safe?
the cookie must be httpOnly - if it’s not, it’s just as safe as localstorage.
what are you using for backend?
@@cdruc golang echo with, jwt and sessions middleware. thx for httpOnly tip, didnt know
where am i supposed to do? cookies seems even worst
"99% of JS code is not even yours"
My website has 0 lines of js code right now and it's all mine
Doing it on the server's side can be dangerous too, cause if the server automatically reads the cookie to auth you, then what if someone wants to do csrf on you? And also what if your backend is php and you installed a sketchy library, wouldn't it work cause it's server side or what? Solution: Just install trusted libraries
LoL, you just want to comment 😂
Where else should I store my tokens then?😅
localStorage is enough
Sounds like snake oil, if you have XSS then you have already a compromised system. I find local storage more straight forward and I only need to care about XSS not some crazy CSRF or extra security headers.
Very good explaination. But what if a npm package tracks all the requests that I am sending with body header and everything including response. How to be safe from that ?
use deno instead of node.
@@mpcref why?
@@tukangeksperimen7844to be safe from the concern you're raising.
So you're basically implying that we should go back to a monolith architecture and use Http-only cookies.
The real message of this video should've been to stop using random ass npm packages lol
Man, unfortunatley i dont handle auth for my app, my DB does and it stores them in localStorage, and, in some parts of my code extracting tokens from it is actually used. For example to auth the same user across different domains. Thanks for the video btw.
make sure to tell people how to not store auth tokens, how to know if they already are.
good video
Guys I think he doesn’t want us to save auth tokens in LocalStorage
maybe 5% of js is not mine, i write everything
I believe most devs write everything
that could also happen in apps...
Simple, don’t use NPM, there I solved it
Awesome!
Discord be like:
Noted 😎 !
tell this to discord
How does this apply to the Microsoft tech stack and azure ad
CSP
nice, but how the fuck are you store secure tokens in a server-less application.
I mean literally, you only get an SPA without any code running on the server other than sending a static file.
every single solution will expose the token in an easily accessible way.
No no no. Localstorage is fine. Cookies are no more secure. So tired of hearing this argument on youtube and medium. Even supabase uses this method.
I mean, everything's on a spectrum. Local storage is more vulnerable to compromised JavaScript dependencies then a http only cookie. Of course, depending on how sophisticated the malicious dependency, it could make api calls to your backend while you're visiting the page in your browser, but that would have to be more targeted.
yeah me too, am tired of hearing this! 😂😂😂🤡
HttpOnly cookies are more secure.
What if i encrypt the token before i store it and decrypt it when i want to use it ?
And where will you store the key for your (symmetric) encryption?
@@qbasic16 if i were using SSR this will be at the server.
@@MedChergui and what's the point on storing an encrypted token on the server? You still have to authenticate the requests from a (valid) client.
@@qbasic16 The encrypted token will be in localStorage (aka Clinet) but the key to decrypt will be in server.
Decrypt it then check if the encrypted token does match.
@@qbasic16 The encrypted token will be stored in the client, but the key will be in server.
The server decrypt the encrypted token and verify the user
Skip the fluff and get to the point.
Why don't encode your auth token then? Even if its stolen it's meaningless to the attacker
Meaningless in what sense? As long as the token is valid proof of authentication, the attacker will be able to use it to impersonate the user they stole it from.
encode? Then the attacker can just decode the token, what are you talking about
@@EpKjelltzer But adding the user ip, and browser or extra info should help mitigate those things, plus a refresh token stored on the server. I mean that's the usual JWT pattern. An attacker could decode it but the token should not be valid from anywhere
To build code above malicious packages is very bad idea. Dislike.
huh?
Are u stupid or smth?
Try giving the video a second watch, it seems like you misunderstood the message of the video.
Bot 😅😂
document.cookie ? :3
You can not access HTTP Only Cookie using document.cookie.
@@mehedimi if i cant read tokens using js. how can i make refresh token to refresh access token when it expires
@@xajiraqabyou simply send a request to the auth server to issue a new token.
@@michaelbitzer7295 how if u cant read refresh token
@@xajiraqabbrowser will do the job