Stop using JWT for sessions, part 2: Why your solution doesn't work(cryto.net)

3 pointsby omgitstomvor 10 Jahren1 comments

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

http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

1 comments

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.

We have an implementation of JWTs @ Stormpath for Token Authentication. We help a lot of customers with token authentication / user management and Stormpath hold a whitelist of all unexpired tokens.

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't been revoked.

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).

The Stormpath Integrations (like Express / Spring / Laravel / etc) use cookies to store the tokens because we have been advocating for cookies as the JWT storage mechanism for a while:

https://stormpath.com/blog/where-to-store-your-jwts-cookies-...