TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Stop using JWT for sessions, part 2: Why your solution doesn't work

3 pointsby omgitstomalmost 9 years ago

1 comment

omgitstomalmost 9 years ago
All of these points are sound. There are some benefits of using a JWT over a session identifier, though. And I think that most of these were covered in the comments of your first post.<p>We have an implementation of JWTs @ Stormpath for Token Authentication. We help a lot of customers with token authentication &#x2F; user management and Stormpath hold a whitelist of all unexpired tokens.<p>In the Stormpath SDKs, there is the ability to locally validate the token for speed or validate against our API to make sure the token hasn&#x27;t been revoked.<p>A common strategy for our customers is to always validate an access token locally, but force refresh against the Stormpath API. This is a good way to not incur state in your application (Stormpath will keep the state for you).<p>The Stormpath Integrations (like Express &#x2F; Spring &#x2F; Laravel &#x2F; etc) use cookies to store the tokens because we have been advocating for cookies as the JWT storage mechanism for a while:<p><a href="https:&#x2F;&#x2F;stormpath.com&#x2F;blog&#x2F;where-to-store-your-jwts-cookies-vs-html5-web-storage" rel="nofollow">https:&#x2F;&#x2F;stormpath.com&#x2F;blog&#x2F;where-to-store-your-jwts-cookies-...</a>