Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use JSON web tokens for sessions

cryto.net

Post reply on HN
Print view View original

11–20 of 153 posts

Re: Don't use JSON web tokens for sessions

#11

Post by monknomo »

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…

I thought you could include a tamper-proof expiration time in the payload of a JWT token? It also seems like data-staleness could be addressed, perhaps by including a hash of relevant data and invalidating/reissuing a token when the hash changes?

Re: Don't use JSON web tokens for sessions

#12

Post by luhn »

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.

Re: Don't use JSON web tokens for sessions

#13

Post by betenoire »

Kiro wrote: post #10
rahkiin wrote: post #6

Earlier quoted context omitted.

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.

It depends on how you define your terms. If you think of the RESTful API and the Authentication mechanism as two separate systems, you can have your cake and eat it too.

We use stateful JWT to "fail fast". That is, we can quickly reject invalid authentication, but we still look up the hash in the database before we actually use it. Our systems that do API and Auth are separate enough that the stateful/stateless distinction isn't useful.

Re: Don't use JSON web tokens for sessions

#14

Post by [deleted] »

Kiro wrote: post #10
rahkiin wrote: post #6

Earlier quoted context omitted.

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.

[deleted]

Re: Don't use JSON web tokens for sessions

#15

Post by monknomo »

Kiro wrote: post #10
rahkiin wrote: post #6

Earlier quoted context omitted.

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.

People seem to really wiggle around what constitutes state, when it comes to auth/autz and REST.

Some people seem happy with a tiny amount of state to manage user sessions, which makes REST harder.

Other people use tokens of one flavor or another, which may have more security vulnerabilities than conventional sessions, although I'm not convinced.

Shared secret HMAC style is another alternative, although I'm not clear how to make that work with javascript clients in browsers.

Some people just throw the whole authentication question into headers and do basic auth.

Re: Don't use JSON web tokens for sessions

#16

Post by EdSharkey »

So, if I'm reading the advice right, then ...

  * Using JWT for authorization, particularly for one-time use == GOOD
  * Using JWT to represent long-lived persistent session state == BAD
and, always transmit your tokens in all directions over HTTPS.

This seems like useful advice given all the reasons put forward. Do I understand correctly or did I miss anything?

Re: Don't use JSON web tokens for sessions

#17

Post by foxbarrington »

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.

Totally, we started doing that and haven't looked back.

Btw, if anyone is looking for an easy way to get going with Node.js check out https://github.com/davidguttman/authentic

Re: Don't use JSON web tokens for sessions

#18

Post by CiPHPerCoder »

EdSharkey wrote: post #16

So, if I'm reading the advice right, then ... * Using JWT for authorization, particularly for one-time use == GOOD * Using JWT to represent long-lived persistent session state == BAD and, always transmit your tokens in all directions over HTTPS. This seems like useful advice given all the reasons put forward. Do I understand correctly or did I miss anything?

That's it in a nutshell. A lot of developers also misuse JWT in strange ways, and the meat of this article was responding to those weird/unsafe use-cases.

Re: Don't use JSON web tokens for sessions

#19

Post by CiPHPerCoder »

kevinastone wrote: post #8

I 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.…

JWT is often used as an implementation of signed cookies.

Also, don't use signed cookies unless you have a crypto expert on staff.

Re: Don't use JSON web tokens for sessions

#20

Post by chrisfosterelli »

I disagree with his argument that JSON web tokens are "less secure". He even quotes this:

> The only way to retrieve data out of local storage is by using JavaScript, which means any attacker supplied JavaScript that passes the Content Security Policy can access and exfiltrate it.

In my opinion, it is MUCH easier to get a CSRF vulnerability than it is to bypass the Content Security Policy. Unless you can get around the CSP and same origin requirement, this makes web tokens far more secure.

He also states that if you store your web token in a cookie you are still vulnerable to CSRF. This is only true if you are using cookie headers to send the token (which is less common), not if you only use it for storage/retrieval of the token.

Lastly, he argues JSON web tokens are not easier to use, but then points out you need a dedicated Redis session store server to scale session authentications. Managing sessions in mobile apps and command line apps is a huge pain compared to JWTs. How is that easier to use?

Post reply on HN