Securely make JWT based authentication in React Application.
In this article, we will see how to securely store the JWT token in a single page app...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Do not do this. This is wrong. Always put JWT in memory, never elsewhere. For the statement about user experience, continue reading.
You should not use jwt cookies with http.only, or whatever... this will force you to develop backend APIs that use cookies instead of bearer tokens...this make your APIs browser dependant. This is Bad, your APIs should be browser agnostic.
The solution can be to only use cookies for your autorisation endpoint (usually something like /login or /authorize ) to do single sign on if you want better user experience. This is a convenient way of doing sso, but there are other secured technologies not relying on cookies.
This authorisation endpoint should be the only endpoint using cookies. If it receives a valid cookie it returns a JWT to the caller else it will redirect the user to the authentication page. As simple as that.
All the other APIs should use the jwt stored in memory and passed as a bearer token. Nothing else.
Am interested in this your approach but I still don't get your explanation correctly. Please if you can create a snippet maybe in GitHub that will be appreciated. Thank you so much👏
What if we specify both in middleware first check if authorization header exists or not and if not then check for cookies. so this way you can support both ways :)
I am also interested in your approach. if you can make your explanations clear, it will really help
I am interested in knowing the secured technologies are you mentioning!
Nice article :)
I'd just add a bit of constructive critiscism (disclaimer: opininiated content ahead)
Saying that localStorage is just unsafe is not entirely true.
You CAN quite easily prevent JS libs from accessing your jwt when stored in localstorage (see my article).
Moreover, if someone with bad intentions can run js on your website, seeing your tokens stolen will be the least of your problems...
And finally, it is very easy to forget that protecting against XSS attacks with cookies will likely make your app vulnerable to CSRF attacks.
Agreed, http-only cookies may be the way to go when you're a cybersecurity ayatollah which knows what he's doing, but if you're building humble SPAs, and you dont know much about security, storing tokens in localstorage may actually be safer: You just have to trust the libraries you depend upon, that's all (while using cookies mean actively protecting your endpoints against CSRF... meaning that you must be conscious of the existence of this technique).
I wrote about "cookies vs localstorage for tokens storage" here:
localStorage vs cookies: the "tabs vs spaces" sterile debate of web development 🙄
Olivier Guimbal ・ Nov 25 '20 ・ 3 min read
I'd recommend this series by Ben Botto on how to approach this securely.
medium.com/@benjamin.botto/secure-...
There's a few ways to handle this. In both companies I worked at, we implemented multiple tiers of token levels. Meaning that what gets stored in local storage is a low-access token. If an attacker got ahold of this, they could only access low-privilige APIs, like read only methods that didn't deal with PCI data.
For higher level access, you require the user to go through an auth flow and a temporary high-access token is issued that uses a session cookie AND the PCI based pages are server-side only.
This has the benefit of still allowing a mostly SPA architecture and you can store tokens in local storage but with added security for pages that deal with personally-identifiable information (PII) or PCI data.
For a pure SPA, the session reverse proxy approach like Ben lays out is probably needed throughout. But for the apps I work on, we do a hybrid client-server. It's still React but all PCI-compliant pages are actually bundled separately and only rendered in SSR.
Other security practices like Content Security Policy, Subresource Integrity, CORS, Same Site cookies, and CSRF prevention help mitigate browser-based attacks too.
Just store it in local/session storage. XSS is not an issue with modern frameworks. Moreover, if you have an xss on your website, it doesn't actually matter where you store your jwts, attacker can just send a request to your api, browser will be more than happy to add cookies to this request.
agreed
What if we are using separate domain for APIs ?
Can we store the cookies in our SPA when we are consuming APIs (domain y) from domain x ?
Now a days browsers blocking 3r party cookies .. if we do so it can break the site right ?
You Can setup cookies with cors by adding Access-Control-Allow-Credentials
and to explicitly setup Acess-Control-Allow-Origin to your main domain.
Also now days its becomes common to block third party cookies in browsers .. in that case if we use diffrent domain it may break the flow right ?
You mean sub domain and main domain ?
Nice article, but I have a question, If I want to design an API that is used by both web and mobile, so how can I design it for mobile?, because mobile doesn't support for cookie like the web. Hope to get reply from you and other contributors.
you want try secure storage, sqlite, sharedpreferences.. etc etc
Thanks for your question.
This approach is only for web, for mobile it is completely different, we need pass the JWT as Authorization bearer token. so we need to go with separate APIs. for example api/mobile/login instead of api/web/login
Nice article, but unfortunately your approach with JWT token in cookie won't work. You said "But remember that this approach only works if the React app and the BackEnd server hosted in same domain." It doesn't matter in this case, a requests will be sent from client browser. React server merely sends html and js code to a client machine.
Session store would work great, and use refresh tokens/ expire the token every couple of mins would do the trick I believe, and also as best practice rotate the SecureKEY in Jwt provider should be followed
Well, I see your reasons above and I appreciate that.
If you can remove every login token from the localStorage when the user logs out or when the user closes the tab, it would be nice.
Well, I don't know much about security but according to some tutors, they recommended localStorage but they warned to clear localStorage on user logout.
Intenta usar sessionstorage. Segun mal no receurdo se borrar al cerrar el a navegador
Thanks for the article, but I have a need where the JavaScript code have to read the token and send it in a HTTP authorization header (axios http equest), how can I achieve this feature ?
If you havce store the Jwt somewhere , you can have a config that says that if the user is logged In , put the Token in the Authorization header in the Axios for each request to the Backend else do not create an Authorization header in the axios request