Don't use JSON web tokens for sessions • Hacker News Board

Re: Don't use JSON web tokens for sessions

#21

Post by fabian2k » Mon, Jun 13, 2016, 8:58 PM UTC

The one thing that I found scary when reading up on JWTs is that there is no way to revoke them. Of course you could check them against a list of revoked tokens on your server, but then your lose the stateless aspect. So the only remaining option to revoke a JWT is the nuclear option, invalidating all JWTs at once.

This seemed like a rather large limitation to me. Related to this, the ability to encode further information in the token, e.g. access rights suffer from the same flaw. If I use the tokens themselves to grant different privileges on a site, I can't revoke those privileges.

I've never used them in practice, this is all just from reading about JWTs. How do people deal with those aspects in practice?

Re: Don't use JSON web tokens for sessions

#22

Post by CiPHPerCoder » Mon, Jun 13, 2016, 8:59 PM UTC

fabian2k wrote: post #21

The one thing that I found scary when reading up on JWTs is that there is no way to revoke them. Of course you could check them against a list of revoked tokens on your server, but then your lose the stateless aspect. So the only remaining option to revoke a JWT is the nuclear option, invalidating all JWTs at once. This seemed like a rather large limitation to me. Related to this, the ability to encode further inform…

> How do people deal with those aspects in practice?

In one word: Poorly.

There is no elegant solution outside what you've outlined here. Or: they use stateful JWTs.

Re: Don't use JSON web tokens for sessions

#23

Post by llmfei » Mon, Jun 13, 2016, 8:59 PM UTC

Kiro wrote: post #3

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

Forget this article. He just doesn't like everybody uses JWT instead of cookie in any case. I still think JWS is a good choice for REST API in stateless session. I don't like to setup a redis server. What you need to do if the redis server cannot support so many users? So use JWT to keep stateless is a good choice.

Re: Don't use JSON web tokens for sessions

#24

Post by ubercore » Mon, Jun 13, 2016, 8:59 PM UTC

So, I've been approaching JWT as a "proof of login" essentially, to handle authentication across web, mobile apps. The only payload I use is relevant to identifying the user logged in. Session data would be handled by server-side code, though it's still early days for me so I haven't had a use for it yet.

After reading this, I'm wondering if I'm misusing JWT, and should replace it for the use-case of authenticating API calls are coming from an identified user in a client agnostic way?

Re: Don't use JSON web tokens for sessions

#25

Post by CiPHPerCoder » Mon, Jun 13, 2016, 9:00 PM UTC

neya wrote: post #5

I 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?

Use sessions for client->server and OAuth2 for server->server.

Re: Don't use JSON web tokens for sessions

#26

Post by bdamm » Mon, Jun 13, 2016, 9:01 PM UTC

pfooti wrote: post #9

What 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 t…

CSRF isn't about content injection or acquisition of session tokens. I think you probably know that but the way you describe "doesn't make you invincible" I'd say a little more strongly; it doesn't do anything at all to prevent CSRF (or XSS!)

Re: Don't use JSON web tokens for sessions

#27

Post by andrewstuart2 » Mon, Jun 13, 2016, 9:01 PM UTC

fabian2k wrote: post #21

The one thing that I found scary when reading up on JWTs is that there is no way to revoke them. Of course you could check them against a list of revoked tokens on your server, but then your lose the stateless aspect. So the only remaining option to revoke a JWT is the nuclear option, invalidating all JWTs at once. This seemed like a rather large limitation to me. Related to this, the ability to encode further inform…

What you've described is literally the same tradeoff you must decide on with caching TTL, but in the arena of credential validity for signed tokens.

In both cases, you're deciding how long something should be valid before it's flushed and must be renewed, or whether you should always check the source.

Re: Don't use JSON web tokens for sessions

#28

Post by joepie91_ » Mon, Jun 13, 2016, 9:03 PM UTC

luhn wrote: post #12

This articles doesn't acknowledge where JWTs really shine: Authentication across a cloud of services, esp. a microservice architecture. JWTs allow a session to be shared across all of the services without any shared state.

I intentionally didn't address this in the article (and went for the "download server" example instead), because there's too much risk of people implementing my (simplified) description verbatim, and ending up with a whole host of security issues.

To address your usecase: This is perfectly possible without using JWTs as a session store. Your individual services will be either stateful or stateless.

If they are stateless, you can simply use single-use tokens that are issued by the application server, and the entire concept of "sessions" doesn't exist as far as that service is concerned. The only thing it cares about, is whether any particular one operation is authorized.

If they are stateful, you can simply maintain a separate session for each of the services. You then use a short-lived JWT token (issued by the application server) to authorize the creation of a session on a non-application-server. The client exchanges this for a session on the non-application-server.

This way you essentially get the best of both worlds. Of course that leaves you to still have to implement (relatively complex) revocation infrastructure yourself for the stateful services, but that's inherent to a distributed architecture.

Re: Don't use JSON web tokens for sessions

#29

Post by gouggoug » Mon, Jun 13, 2016, 9:04 PM UTC

luhn wrote: post #12

This articles doesn't acknowledge where JWTs really shine: Authentication across a cloud of services, esp. a microservice architecture. JWTs allow a session to be shared across all of the services without any shared state.

It does actually acknowledge it, at the end of the post: "So... what is JWT good for, then?"

Re: Don't use JSON web tokens for sessions

#30

Post by vonklaus » Mon, Jun 13, 2016, 9:05 PM UTC

there was an article on here which I found more in depth than this, about why tokens are a good way to do auth.

Im on mobile, but it was ~6 days ago if someone digs it up. However, I guess I don't understand what the actual argument is.

Vue js sets the header to auth bearer and pulls from local storage. I have a token and I verify the id in the payload, the subject which is usetname, expiration and the issuer.

If we assume this goes over SSL/https what is the attack vector. The other article (and this) basically say someone can run a script and get the token however it is pointed out that if soneone can run arbitrary code on your site or users machine, then you already lost anyway.

What am I missing?