I will have use the client side when the app goes in PWA(Progressive Web App) mode. So i was thinking to set a cokkie server side with expiration of one day. But then again i will get into the problem that my client can’t verify if the cookie expired.
wolfiton
Yama
Hello @victorolinasc Thank you for replying and providing links to better understand. I loved the video presented in User management with absinthe for api by @wolfiton which had a discussion why JWT isn’t safe and how vernible it is in comparison to a session token. That is something I never knew since most of my friends who have been in tech longer than I have (just landed my first job a few months ago) all recommend adding JWT to your application.
Although I would like some clarity. The Stack I’m implementing for this project currently is BE - PostgresQL, Phoenix/Elixir and Absinthe/GraphQL as for the FE - React/Apollo.
After reading the link regarding cookies and how it’s being send from the FE to the backend as a header I’m now becoming confused with the purpose of JWT. I thought its use was to mainly send a userID to the frontend and save their information in order to persist that a user . is logged in. We then use that ID to find the user and check if it matches to lets say their email when logging in.
The way I saw it was not save any information into a JWT except for the user ID that we can use to look them up when logging in. After logging in we should just save the ID? or do people normally save the entire User? and if yes why is this the case when it’s a risk of leak occurring?
Also am wondering if cookies are safer as most including OWASP have stated, would it be recommended to use backend to check the cookie is valid before sending information back? if we wanted to persist some information should we for example in regards to cookies
1 - hit backend when logging in
2 - save user to cookies
3 - send logged in user information (mainly use the ID) and save to a state management like Redux as current_user: 1
4 - This will be our false catch to use when trying to validate a user interaction to the frontend?
Reason I mentioned redux is because I don’t have much experience with Apollo/Client yet.
Again thank you for clarity and also providing your experience/feedback on this matter.
0
LostKobrakai
If you need to handle auth client side (without the server being available) then cookies are not useful to you. Cookies are only a good storage for session IDs/data because http only ones cannot be read/modified by the client and the server handles everything related to authentication. Once that’s out of the picture you need to look for alternatives.
1
Yama
Hello @LostKobrakai Thanks for replying to this post. I’m starting to question a lot of things. I know when I build personal projects at a bootcamp we never used JWT but instead a session token. I haven’t done a project in a while since I got hired and as I’m about to build a project different questions have appeared, especially the use of JWT since most of my friends who has been hired much longer have said it is required in all apps, one main reason for this post was better understand the purpose and reason.
The more I read, the less I understand the reason behind JWT. Since now that I think about it, if we want to have restriction or authentication, we can have it check the cookie at every request and in a login just send the user as the current user to the frontend to be kept in a state management, right? Or is there a form of authentication that can be done with a token for the frontend as well? (new questions are coming to mind the more I’m seeing these post)
Again thanks for the feedback and opinion. Sorry if I’m also lacking in knowledge.
0
wolfiton
Thanks @LostKobrakai, for the idea, but figure some time ago that using a hhtp only cookie will not help, so going the jwt path seems like a dangerous road.
So maybe just use the cookie server side and when the client goes in pwa(offline) let it be and verify everything once it gets online again might be a better option.
Have you encountered this type of solution is it achievable?
0
Yama
@wolfiton That is something I never considered (also I just learned what PWA means from you so thank you for that one). I can see now why we would want some form of frontend validation. But couldn’t we mostly just for example save the user that logged in as current_user to a value in a cache/state management and then use that to verify if they are allowed to do something while access to the backend is unavailable? such as if current_user_id does not match the post.user.id (bad example) then we can’t allow them to make any changes? Just a thought.
0
wolfiton
Everything that is in JS is vulnerable to XSS Attack. So the state management falls under this category. Also if we do that then we will fall under the JWT path.
So it is not a very good solution.
0
wolfiton
One other thing to consider in pwa while offline is:
- do we let users make changes(and then updated them once online again)
- or only allow them to view the content
So many things to consider, so very little time
0
Yama
@wolfiton That is something I’ve been learning since I posted this question. How unsecure JS really is compared to when using cookies. But I also agree with so little time. I’m in the process of building to MVP ideas which also places security as important since 1 uses credit cards (maybe this can be resolved with Strip and if not I’ll use PayPal for safety). The other doesn’t have credit cards involved but I want my future clients to feel secured using my application since I really care about security.
0
LostKobrakai
I’m not sure if unsecure is the correct term. The problem is rather in access restrictions. If you give someone a repl to your server side elixir your secrets are just as well hidden as when putting them on the client in places where stuff is readable by javascript.
0