<p>I assume you already know JWT and how to implement it so I won’t bore you with the basics. Let’s jump straight into it.</p>
<h1>Here’s a direct quote from Microsoft’s documentation:</h1>
<blockquote>
<p>“Storing tokens in vulnerable client-side storage can lead to significant security vulnerabilities. For example, storing access tokens directly in the browser using local storage, session storage, or web workers.”</p>
</blockquote>
<p>Yet, despite this warning, many tutorials and examples online still recommend storing JWTs in browser storage I, too, used to store and retrieve JWTs directly from browser storage, because of these examples, essentially leaving the key right under the doormat.</p>
<h2>Why Storing JWTs in Browser Storage Is a Bad Idea</h2>
<ol>
<li>localStorage – Vulnerable to XSS (Cross-Site Scripting) attacks.</li>
<li>sessionStorage – Also vulnerable to XSS; the only difference is that data is wiped when the browser closes, whereas localStorage persists.</li>
<li>Cookies – Susceptible to XSRF (Cross-Site Request Forgery) attacks unless properly secured.</li>
</ol>
<h2>Why Do We Still Use Browser Storage?</h2>
<p>The main reason is convenience. It’s easy to retrieve the token and pass it along with an HTTP request. However, persisting JWTs in browser storage exposes them to any JavaScript running in the application. For example, retrieving a token is as simple as:</p>
<p>localStorage.getItem(‘someKey’);</p>
<p>If user input isn’t properly sanitized, a hacker could inject JavaScript and do the same.
“But if we’re using frontend frameworks like Angular, aren’t inputs sanitized by default?” Yes, Angular automatically sanitizes input, and other frameworks/libraries likely do the same. However, this alone is not enough.</p>
<h2>Here’s why:</h2>
<ol>
<li>Third-party JavaScript libraries – If a malicious library is added  to our client site application, it can access browser storage and steal sensitive data.</li>
<li>Browser extensions – If an extension has excessive permissions, it can read the browser’s storage and extract JWTs.</li>
<li>A game released on Steam (PirateFi) has malicious intentions of stealing information persisted in the browser storage mechanism (e.g., localStorage, sessionStorage, Cookies, etc.)</li>
</ol>
<p>What About Cookies?</p>
<p>By default, cookies are not secure unless specific security flags (e.g., httpOnly, Secure, SameSite) are enabled. If JWT is manually stored in cookies from the client side, JavaScript can still read them making the cookie just another vulnerable storage mechanism. If the cookie is flagged as httpOnly, the client-side application won’t be able to access the JWT.</p>
<h1>The Dilemma: Security vs. User Experience</h1>
<p>If we don’t store JWT in any browser storage, users would need to re-authenticate every time they refresh the page. Since the client-side state resets upon refresh, this would force the user to re-enter the credentials which will lead to poor UX
So how do we balance security and good UX? 🤔We implement a silent way to issue a JWT, next is what I do.</p>
<ol>
<li>Enforce HTTPS to encrypt the communication between the client and server.</li>
<li>Use app.UseHSTS middleware in production to prevent downgrades to HTTP</li>
<li>Don’t persist the JWT use it in-memory</li>
<li>Implement refresh token mechanism</li>
</ol>
<p>By not persisting the JWT in the browser storage, we mitigate the attacks on the browser storage mechanism its not foolproof but its an improvement, but we still want to persist the user being login after a browser refresh so how does we do that with the refresh token.</p>
<h2>Heres my authentication flow for the backend.</h2>
<p>When a client attempts to log in, the backend generates a JWT upon successful authentication. At the same time, it also generates a refresh token, which is not included in the response body but is instead set in the response header as an httpOnly cookie. This refresh token is also stored in the AspNetUsers table in my case.</p>
<p><img src="https://media.daily.dev/image/upload/s--HmNBbNu1--/f_auto/v1740536689/ugc/content_71fbd15b-e718-4ae6-94be-4ca00c191b7e" alt="Screenshot 2025-02-26 032417"></p>
<h3>To ensure security:</h3>
<ol>
<li>The httpOnly flag prevents JavaScript access, mitigating XSS attacks.</li>
<li>The Secure flag ensures the cookie is only sent over HTTPS.</li>
<li>The SameSite=Strict setting mitigates CSRF attacks, meaning the client-side application and API must be on the same domain; otherwise, the refresh token will be invalid.</li>
</ol>
<p><img src="https://media.daily.dev/image/upload/s--IYFSyEfA--/f_auto/v1740537273/ugc/content_5093e5fd-281c-4ca8-b534-465a7cb6a273" alt="Screenshot 2025-02-26 033404"></p>
<ol start="4">
<li>The Path is set to / to allow the refresh token to be sent from all endpoints.</li>
<li>The Expires attribute is self-explanatory, defining the token’s validity period.
With this setup, we maintain a single source of truth and enable JWT revocation by invalidating the refresh token.</li>
</ol>
<h2>Client-Side Implementation</h2>
<p>On the client side we implement a interceptor, whenever we encounter:</p>
<ol>
<li>A 401 Unauthorized response,</li>
<li>A browser refresh, or</li>
<li>The ngOnInit lifecycle hook in app.ts
we should call the refresh endpoint to validate whether the refresh token stored in the cookie matches the one in the database.</li>
</ol>
<p>•	If valid:</p>
<ol>
<li>Generate a new JWT for the client.</li>
<li>Generate a new refresh token and store it in both the database and the cookie.</li>
</ol>
<p>•	If invalid:</p>
<ol>
<li>Remove the refresh token from the cookie storage.</li>
<li>Invalidate the previous refresh token in the database.</li>
<li>Redirect the user back to login screen</li>
</ol>
<p>By following this approach, we ensure that only the last successfully logged-in device that has a valid refresh token stored in the cookie can access the protected resources</p>
<p><img src="https://media.daily.dev/image/upload/s--Bs8Aj1st--/f_auto/v1740536872/ugc/content_96eb1b8b-32b7-496a-b42a-55cf70a013d9" alt="image"></p>
<h2>Example Use Case</h2>
<p>If a user forgets to log out from a work device and later logs in from their mobile device, the work device’s refresh token becomes invalid. The next time the work device attempts to access a protected resource (e.g., via a browser refresh or during ngOnInit), it will be redirected to the login page because the refresh token no longer matches the database record.</p>
<p>I want to emphasize the importance of a short-lived JWT token something between 5-15 min because, JWT cannot be easily revoked once issued. In the scenario above, if the application remains open, the issued JWT is still valid until it either expires or a browser refresh occurs. The ngOnInit lifecycle hook will not execute since the SPA has not been closed.</p>
<p>you could change the value of your JWT secret but that’s a very destructive action and will be imposed on all users that currently logged in. Its better to stick with a short-lived JWT and depends on how aggressive you want you could turn the JWT to have a lifespan of only 5 min.</p>
<h3>lastly, I want to add an example  we all should avoid,</h3>
<p>Ive seen example where JWT are being persisted in the sessionStorage, the token have a long expiration duration lets say 1 month, when the browser closes, the session storage is wiped. But if you click “remember me” which is an options I often see, then the JWT is being moved from sessionStorage to localStorage. This is a bad idea, if you have read the above you can imagine why this is a bad idea, alternatively we could increase the expiration of the refresh token instead.</p>
<p>I know this solution isn’t foolproof, but I think I’m pretty close! I believe adding a Content Security Policy (CSP) could help mitigate XSS attacks from third-party libraries, but I need to research that further.</p>
<p>Feel free to correct me if I’m wrong or share a better approach!</p>


All about .NET, C#, and ASP.NET Core. News, tutorials, articles, projects, and more. 

.NET

Storing JWTs in vulnerable client-side storage (like localStorage, sessionStorage, or cookies) can expose applications to significant security risks. Alternatives include using in-memory storage and implementing a refresh token mechanism. This allows users to maintain their sessions without re-authenticating upon page reloads while mitigating potential attacks. Setting cookies with httpOnly, Secure, and SameSite flags is crucial for security. A short-lived JWT with periodic refreshing enhances protection.

Do you store the JWT in localStorage, sessionStorage, Cookies? then this post is for you

<p>I do not fully agree with you</p>
<p>Yes you need access and refresh tokens.
But store the last refresh token in database is rarely whr you want.
For example, as a user, I want to stay logged on my laptop but also on my smartphone. If I switch devices I will need to authenticate every time.</p>
<p>But you’re right, we must not save access token. I also save it in local storage and that is bad practice!</p>
<p>I’m doing n SSO app for multi domain, and I think it is bad to code it by myself.
I think when we need to handle authentication, it is better to use known projects, as keycloak or authentika for example.</p>


<p>HTTPOnly same-site secure cookie solves all of your problems. Refresh tokens shouldn’t include just the last one, as you might want to login on different devices. Just make sure your lifetimes are reasonable! (30 mins - 2 hours for JWT and 7 - 30 days for refresh token).</p>


<p>Great information!, to add to it,
nothing is safe, in computer world, something that sounds secure today, might be exploited, later.</p>
<p>There are subjective good and bads ways of doing, and these generally, come from what you are doing with them, the project, the library, may also be your general coding experience.</p>
<p>Is it safe to use cookies and JWT, universally, ‘NO’,
But to some extent, where you have other mechanisms to cope with it,</p>
<p>HTTPS, httponly, CSP’s etc, even storing the IP’s of users for detecting users that pose threat to the entire server.</p>
<p>but again, do you really need that, how important is your user data (not just their name, email) but in general the data they work with.</p>


<p>And why not “just” a KISS : Basic auth + https… after all ?</p>


<p>I think you never mentioned that to re-write the JWT we need the secret… I can read any JWT and that’s not a problem (if you’re not storing sensitive information). The “XSS” or other vulnerabilities will appear if someone can “guess” (crack) your secret ;)</p>
