taniarascia / comments

Comments
7 stars 0 forks source link

full-stack-cookies-localstorage-react-express/ #82

Open utterances-bot opened 3 years ago

utterances-bot commented 3 years ago

Client-side Authentication the Right Way (Cookies vs. Local Storage) | Tania Rascia

The expectation When you log into an application, you have the expectation that the next time you open a new tab or window in the browser…

https://www.taniarascia.com/full-stack-cookies-localstorage-react-express/

aalzubidy commented 3 years ago

Thank you for the article. I think there is a newer more recommended approach on securing JWT in react/node. This also enables you to host the authentication server in a different place from the other features, which would help in load balancing if needed. https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/#jwt_structure

Also, I would not recommend serving react from inside the express server for big applications, if one thing goes down, the other can stay up and its easier to scale only parts of the solution instead of the entire thing.

taniarascia commented 3 years ago

I'm not sure how that first link relates to anything. Could you please elaborate? In this example, the authentication server is a different server from the React/Express server. However, if PKCE is available to you, you can have secure authentication without going through this shared React/Express front end, but this tutorial assumes that it is not.

aalzubidy commented 3 years ago

I might have misread your post then, if you're assuming they must be served together that's fine. Yes, the link I shared for an approach that they should not be served together.

GaboUCR commented 2 years ago

Hi, I want to know (out of pure curiosity) why the use of async in the handlers and what would happen if one doesn't use it. Thank you so much for your work Tania, it's great as always.

ElanMedoff commented 2 years ago

Another requirement for this setup is that the app isn't a forum or something like that -- if it is, a malicious user could post a link that a victim sees on the app and clicks on which submits a request the victim did not intend. Since the link/request originated from the app itself (vs a third party malicious site) the same-site cookies won't help. For something like this, you'd need the setup that aalzubidy referred to, where you store an access token in javascript memory, a refresh token in same-site http-only cookies, and a list of valid refresh tokens on the server. I built a demo with this setup a while back https://github.com/ElanMedoff/jwt-auth