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

JSON Web Tokens vs. Sessions

float-middle.com

Post reply on HN
Print view View original

131–140 of 173 posts

Re: JSON Web Tokens vs. Sessions

#131

Post by pags »

areed wrote: post #101
joepie91_ wrote: post #83

Earlier quoted context omitted.

Better remove that again. It is extremely dangerous to store any kind of credential in Local Storage. Cookies are the (only) correct place for storing credentials.

Because you can set Secure and HttpOnly flags on cookies? This merely brings them up to the same level of security you get with Local Storage. http://blog.portswigger.net/2016/05/web-storage-lesser-evil-...

What is a "level" of security? If I'm able to inject arbitrary code into your page, with it I can access your local storage data, but I can't access your "http only" cookies - so there's at least some "level" of difference.

Re: JSON Web Tokens vs. Sessions

#132

Post by bigonlogn »

StevePerkins wrote: post #14

For people using JWT as a substitute for stateful sessions, how do you handle renewal (or revocation)? With a traditional session, the token is set to expire after some period of inactivity (e.g. one hour). Subsequent requests push out the expiration... so that it's always one hour from the last activity , rather than one hour from initial authentication . With JWT, the expiration time is baked into the token and see…

JWT is just a token. It's not some panacea of client-side only authentication. There are a lot of people lamenting the difficulty in performing logout via JWT. I believe people are missing the point. The failing isn't with JWT, it's with the implementation of the session system.

Typically with sessions the client has a session key. The key gets sent to the server where it looks up the session (via. memory, cache, database, whatever). You can create a new session, validate an existing session, or end a session. All using that key. They only difference between JWT and cookies is JWTs aren't automatically sent with every request. You have to explicitly send them. I believe this is a good thing. It avoids some common attack vectors.

Re: JSON Web Tokens vs. Sessions

#133

Post by lllorddino »

bigonlogn wrote: post #132
StevePerkins wrote: post #14

For people using JWT as a substitute for stateful sessions, how do you handle renewal (or revocation)? With a traditional session, the token is set to expire after some period of inactivity (e.g. one hour). Subsequent requests push out the expiration... so that it's always one hour from the last activity , rather than one hour from initial authentication . With JWT, the expiration time is baked into the token and see…

JWT is just a token. It's not some panacea of client-side only authentication. There are a lot of people lamenting the difficulty in performing logout via JWT. I believe people are missing the point. The failing isn't with JWT, it's with the implementation of the session system. Typically with sessions the client has a session key. The key gets sent to the server where it looks up the session (via. memory, cache, dat…

Is there anything wrong with saving the token in the cookie? I'm not exactly sure how to save them in the header. I'm guessing save it to localStorage and use javascript to pass it back to the server?

Re: JSON Web Tokens vs. Sessions

#134

Post by zbjornson »

pkulak wrote: post #104
zackmorris wrote: post #37

Earlier quoted context omitted.

I know this works, and I've used it, but I also find it to be the most aggravating thing about JWT and also OAuth. With OAuth, some sites allow you to refresh a token after it times out (so really the refresh token is the source of truth, defeating the purpose of the OAuth token), and others only allow you to refresh before it times out (forcing a login by the user if they are disconnected too long, or storing their…

It's not dumb if you do it right. Think of it this way, the _real_ token is your refresh token. It's stored in your database. You control it and it can be revoked at any time. So, now you build 100 other services, and they all accept this refresh token. Problem is, since you control it so well, every other service now needs to validate that refresh token with the auth service on every request. It would be really nice…

For many applications, not being able to immediately log out is an unacceptable trade-off. If you know your account has been compromised and you need to kill all sessions ASAP, an hour delay is unacceptable.

Re: JSON Web Tokens vs. Sessions

#135

Post by lobster_johnson »

DenisM wrote: post #130
atombender wrote: post #51

Earlier quoted context omitted.

This misses one huge benefit of JWTs: Other parties can trust your token if they were not the ones to sign it. For example, say client A calls service B, using a token signed by service C. Previously, we were using randomly generated session keys, which meant B had to ask C every time. But with JWTs, B can directly verify that the token is genuine without asking C, because it has C's public key. We still check with C…

The entire last paragraph of my pevious post describes one way to deal with it, without consulting a central session store.

By previous post, did you the bit about "Federation becomes moderately difficult"?

I don't know if you've ever developed microservices, but building this logic into every single microservice would be a lot of work. We have dozens of microservices, written in different languages, so even if we wrote some generic glue as a library, we'd have to write it at least three times (Go, Ruby and Node.js).

Re: JSON Web Tokens vs. Sessions

#136

Post by zbjornson »

jcoffland wrote: post #74
kensign wrote: post #63

Earlier quoted context omitted.

use a ttl on like a cache store, such as redis

Yes, but this is still a deadend.

How so?

It's effectively a micro-optimization that will have no real effect, but you can do a simple "exists" query when searching the revocation list, and the TTL keeps the collection small.

Not advocating for JWT as it's a silly mess to do everything correctly, but it is possible.

Re: JSON Web Tokens vs. Sessions

#137

Post by baseonmars »

jontro wrote: post #48
btdiehr wrote: post #12

Earlier quoted context omitted.

Why do you think you can't invalidate a JWT? Store a JWT that is associated with some object in a database that has the field `isInvalidated`. This isn't rocket science. Sure - this turns the JWT token into a session but there is no way to invalidate based on something that isn't determined at creation time without storing something in a database.

What's the point of using a JWT if so? This effectively converts it into a session token

You can create a JWT without writing to a datastore - this is a key difference.

Re: JSON Web Tokens vs. Sessions

#138

Post by jastanton »

lllorddino wrote: post #133
bigonlogn wrote: post #132

Earlier quoted context omitted.

JWT is just a token. It's not some panacea of client-side only authentication. There are a lot of people lamenting the difficulty in performing logout via JWT. I believe people are missing the point. The failing isn't with JWT, it's with the implementation of the session system. Typically with sessions the client has a session key. The key gets sent to the server where it looks up the session (via. memory, cache, dat…

Is there anything wrong with saving the token in the cookie? I'm not exactly sure how to save them in the header. I'm guessing save it to localStorage and use javascript to pass it back to the server?

This article talked a bit about putting them in cookies:

  The header method is preferred for security reasons - cookies would be susceptible to CSRF (Cross Site Request Forgery) unless CSRF tokens were used.

  Secondly, the cookies can be sent back only to the same domain (or at most second level domain) they were issued from. If the authentication service resides on a different domain, cookies require much more wild creativeness.
As far as putting something in the header, if you're using javascript check out superagent. It's as easy as:

  request(url).set('SomeHeader', 'SomeValue');
or the latest http fetch api just do:

  var request = new Request('/users.json', {method: 'POST', 
    headers: new Headers({'Content-Type': 'text/plain'})
  });

  fetch(request).then(function() { /* handle response */ });

Re: JSON Web Tokens vs. Sessions

#139

Post by lightbendover »

zackmorris wrote: post #37
moyok wrote: post #21

Earlier quoted context omitted.

For this, you can use refresh tokens and set the JWT expiration to a low interval - say 10 minutes. After every 10 minutes, the JWT expires,authentication fails, and the client uses the refresh token to get a new JWT. To revoke a client, revoke their refresh token. This way, though they won't be logged out immediately, they would be logged out in a max of 10 minutes when they need to refresh again, and find out that…

I know this works, and I've used it, but I also find it to be the most aggravating thing about JWT and also OAuth. With OAuth, some sites allow you to refresh a token after it times out (so really the refresh token is the source of truth, defeating the purpose of the OAuth token), and others only allow you to refresh before it times out (forcing a login by the user if they are disconnected too long, or storing their…

> The JWT library I'm using in Laravel blacklists tokens by storing them in their own table, rather than invalidating them.

The main rationale for JWTs is that it removes the session store as a point of contention (and secondarily it resolves some xdomain issues that aren't that difficult to work around anyway). If you're going to introduce a new table/cache, you're likely better off just using sessions.

Totally agree about timeout management.

Post reply on HN