Don't use JSON web tokens for sessions

Post by ForHackernews » Tue, Jun 14, 2016, 3:33 AM UTC

low_key wrote: post #86

lynndylanhurley wrote: post #69

Earlier quoted context omitted.

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. I think one of the benefits of some (most?) JWT implementations is that it doesn't hit the database on every request - the token is only validated against a global secret. So you can't invalidate a single user's session without invalidating…

I keep a counter in the JWT to at least mostly get around this issue. When processing a request, the counter is checked for the user, which isn't a big deal since all of the requests already require looking up the user. A counter increment invalidates all of that user's existing tokens. If a user changes their password, their roles change, etc, then the counter gets incremented so all tokens issued up to that point w…

Post by sk5t » Tue, Jun 14, 2016, 4:03 AM UTC

NathanKP wrote: post #54

merb wrote: post #39

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. They are less secure Compared to what? Actually JWT will have the same secureness like Bearer Tokens or Cookies, wherever you store it, its not `less` secure. Horrible article points here. They are less secure They take the same amount of s…

You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. Exactly. Each JWT I generate has a salt inside which I store in the DB, and ideally the salt has accompanying data such as the datetime the JWT was generated, the IP address that generated it, etc. Now you can provide an interface that lists "sessions" and allows the invalidation of logged in sess…

Post by ademarre » Tue, Jun 14, 2016, 4:48 AM UTC

mcherm wrote: post #111

lynndylanhurley wrote: post #69

Earlier quoted context omitted.

You cannot invalidate JWT tokens This is simple not true. You ALWAYS will sign your tokens with a well known secret, you could eventually even add some salt from a database to it. I think one of the benefits of some (most?) JWT implementations is that it doesn't hit the database on every request - the token is only validated against a global secret. So you can't invalidate a single user's session without invalidating…

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session. Just as if you were storing state on the server, it still requires a means of propagating the user's state to every server. But we only need to propagate a single ID once per session (at logout) instead of propagating all the session data to all the servers on every request.

Post by hueving » Tue, Jun 14, 2016, 6:06 AM UTC

sb8244 wrote: post #114

mcherm wrote: post #111

Earlier quoted context omitted.

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session. Just as if you were storing state on the server, it still requires a means of propagating the user's state to every server. But we only need to propagate a single ID once per session (at logout) instead of propagating all the session data to all the servers on every request.

Do you ever worry that, in the case of failure or some other event, your revocation list could be lost and allow old hacked sessions to be used? Is there a way around this? I like the idea of a revocation list, but this seems to be a pretty big concern.

Post by merb » Tue, Jun 14, 2016, 7:02 AM UTC

sb8244 wrote: post #114

mcherm wrote: post #111

Earlier quoted context omitted.

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session. Just as if you were storing state on the server, it still requires a means of propagating the user's state to every server. But we only need to propagate a single ID once per session (at logout) instead of propagating all the session data to all the servers on every request.

Do you ever worry that, in the case of failure or some other event, your revocation list could be lost and allow old hacked sessions to be used? Is there a way around this? I like the idea of a revocation list, but this seems to be a pretty big concern.