I took a read on securing JWT based services on https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html . In this guide its told that how to handle JWT token on client side
Automatically sent by the browser (Cookie storage).
- Retrieved even if the browser is restarted (Use of browser localStorage container).
- Retrieved in case of XSS issue (Cookie accessible to JavaScript code or Token stored in browser local/session storage).
How to Prevent
Store the token using the browser sessionStorage container. Add it
as a Bearer HTTP Authentication header with JavaScript when calling services.Add fingerprint information to the token. By storing the token in browser sessionStorage container it exposes the token to
being stolen through a XSS attack. However, fingerprints added to
the token prevent reuse of the stolen token by the attacker on their machine. To close a maximum of exploitation surfaces for an
attacker, add a browser Content Security Policy to harden the
execution context.
The solution limitation provided by OWASP
The problem is that, if the user enters the same URL in an another tab in the same browser, he should not be presented a login page instead should be directed to the homescreen without any login process. To solve this problem . i have followed the below approach. BTW i'm using refresh token to support sliding session
- The user enters login username and password
- After validating the login credentials, the access token is stored in a non httponly, secured, samesite cookie and the refresh token is stored in secured, samesite, httponly cookie
- A fingerprint value is added with a combination of different user context embedded with token information. This fingerprint cookie value is also stored in secured, samesite, httponly cookie and it changes on every new access token provided to the client.
- The Fingerprint value is to prevent tokensidejacking. Even if the access token is stolen from the cookie . The attacker will not be able to use it since the fingerprint information is missing
- On each request, the browser client will need to send the access token as a Bearer token in the header by fetching the access token existing in the cookie . This serves both as a CSRF prevention mechanism and user authentication mechanism.
- If the token expires, the browser will call the refresh token URL and since the refresh token cookie is already present , the server will auto pick up the refresh token and provides a new access token and refresh token. and the step 2 happens again
So is this approach safe and secure? Since the counter measures for tokensidejacking is applied. should i worry about storing access token in a non httponly cookie?
NOTE : The reason i do not store both access token and refresh token in a In-Memory javascript variable because, these token needs to be shared across multiple applications that are hosted on the same domain.
