Don't use JSON web tokens for sessions
1–10 of 153 posts
Re: Don't use JSON web tokens for sessions
#2I'm working on a personal project and use JWT for sessions. The main reason I did this is that my understanding is that it makes it much easier to implement sessions on mobile apps. Is this true? If so, should I continue using them? If not, why do I think that, and how can I future-proof my API with mobile apps in mind?
Re: Don't use JSON web tokens for sessions
#3How else would you do it if your backend is a REST API and you want to keep it RESTful? JWT seemed like a good solution until I read this.
Re: Don't use JSON web tokens for sessions
#4You should probably be using refresh tokens (https://auth0.com/blog/2015/10/07/refresh-tokens-what-are-th...) to invalidate sessions on a change-password event for example.
Re: Don't use JSON web tokens for sessions
#5I am writing my own framework in Scala and I found a similar good article on this topic:
https://stormpath.com/blog/where-to-store-your-jwts-cookies-...
But then, I'm now even more confused as the others here. How exactly am I supposed to secure my REST API now?
Re: Don't use JSON web tokens for sessions
#6How else would you do it if your backend is a REST API and you want to keep it RESTful? JWT seemed like a good solution until I read this.
You would do it by adding a Redis server that stores stateful sessions (mentioned in the article).
I however disagree with most of the points made in the article, and use stateless JWT myself.
Re: Don't use JSON web tokens for sessions
#7Postgrest (http://postgrest.com/) uses JWT to switch between database roles.
Re: Don't use JSON web tokens for sessions
#8I think this assumes that people are switching from server-backed sessions to JWT. I'd expect instead that most people (and frameworks now-a-days) use signed cookies instead. Switching to JWT just standardizes that format a bit to allow non-web clients (like mobile apps) to use a similar session.
I think Armin Ronacher's blog post[0] is a good overview on the benefits of using signed client storage for session state.
[0]: http://lucumr.pocoo.org/2013/11/17/my-favorite-database/
Re: Don't use JSON web tokens for sessions
#9What I do: I use tokens (rather than cookies), but I don't use JWT, for some of the reasons listed in the post, such as "can't expire" and "data goes stale". Instead, after authenticating a user, I issue a long piece of random (256 bits of random packed into a base64 string) to the user. I use the same string as a redis key whose value is the actual user ID of the authenticated user.
That way the front end can pass the token to the back end, I can authenticate and authorize using the redis data (I could store more data in redis, but instead I hit postgres for any other data about the user, such as admin roles, when needed during the authorization process).
It's true that this doesn't make you invincible to CSRF or XSS - any attacker who goes through the trouble and gets access to the token via MITM (although I only use HTTPS, that's not a guarantee) or by injecting javascript in the webapp itself (through user-editable content from a malicious user), that attacker suddenly has full access to the user's account. Still, it's a pretty reasonable way to deal with session problems.
I also set expiry timeouts on these tokens and can delete them manually if a user wants to end all sessions (say on password change). Deleting by value match isn't super-straightforward in redis, but it's also possible with a bit of LUA.
Re: Don't use JSON web tokens for sessions
#10How else would you do it if your backend is a REST API and you want to keep it RESTful? JWT seemed like a good solution until I read this.
You would do it by adding a Redis server that stores stateful sessions (mentioned in the article). I however disagree with most of the points made in the article, and use stateless JWT myself.
Wouldn't that violate the RESTfulness? I thought stateless was one of the criterias.