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

111–120 of 173 posts

Re: JSON Web Tokens vs. Sessions

#111

Post by yxhuvud »

jcoffland wrote: post #71
Alex3917 wrote: post #57

Earlier quoted context omitted.

> storing the "real" expiration in cache so that it can be extended (or revoked) as needed. You can also have a password_last_changed field on your user model, where any token issued before this date is considered invalid. That was if a user's account somehow gets compromised, all they need to do is change their password and then all of their existing sessions are expired automatically. I can't think of any good reas…

Your missing the whole point. If the server was to track password_last_changed it might as well just track user_currently_loggedin.

No, there is a huge difference in write load between those two options.

Re: JSON Web Tokens vs. Sessions

#112

Post by Bombthecat »

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…

As someone working with it, we use it only for machine to machine communication.

There it is easy to reauth. I don't think jwt was ever ment to used in browsers..

Re: JSON Web Tokens vs. Sessions

#113

Post by Bombthecat »

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 refresh token doesn't defeat the purpose of oauth. The purpose is that the third party needs to check in again to refresh.

This gives the end user the time to revoke the token at the provider without the need to revoke or even trust the third party.

Re: JSON Web Tokens vs. Sessions

#114

Post by yxhuvud »

wtbob wrote: post #102
mschuster91 wrote: post #54

Earlier quoted context omitted.

> You can include a JWT as an access_token URL parameter, which works in a GET: Only works with IE > 11, and even IE 11 breaks down sometimes. Also, search engines choke on large URLs, see http://stackoverflow.com/a/417184/1933738

Ummm, every browser for decades has supported URL parameters. I can't believe that IE breaks with them. Yes, large URLs are an issue, but not with search engines & access tokens, since search engines shouldn't ever see access tokens. A JWT should be lightweight — if it's big, then it's wrong.

There are length restrictions for get parameters in older browsers.

Re: JSON Web Tokens vs. Sessions

#116

Post by jayd16 »

StevePerkins wrote: post #76
jcoffland wrote: post #69

Earlier quoted context omitted.

"1. Re-authenticate from the browser every hour and store a new JWT token, which is kind of an awful user experience" The old token can be used to request a new token with an extended expiration, before it timesout. This can easily happen behind the scenes, so it does not affect the user experience at all. The real problem is that you cannot enforce logouts. If you just accept that you cannot 100% enforce logouts and…

Right. You can't logout, and you can't extend the expiration time without the user granting an "offline access" scope during the login process. So WHY exactly is this better than a simple distributed session store (e.g. Redis or whatever), with a browser header or signed cookie as the cache key? That's the underlying premise of all this recent discussion that eludes me. It seems an argument could certainly be made th…

I think your issue is that you're trying to wrap Google's auth in your own jwt implementation. This setup can only prove your own trust of the tokens you create.

You can have a user auth with google and provide you a user id, you can then slap that id into a token and know that you gave that token to the right user and the info inside that token is what you put there. It does NOT let you keep other sessions alive on its own. You won't be able to get around Google's expiry this way if you need a valid auth to Google's APIs.

What it does do is let you auth a user through google once at the beginning of your own app's session, and not have to keep track of session in your own database or hit google multiple times in a user session.

Re: JSON Web Tokens vs. Sessions

#117

Post by digitalpacman »

madeofpalk wrote: post #103
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…

> the client uses the refresh token to get a new JWT What's the point of using the JWT then? If the refresh token lasts for longer than the JWT, and you need to send it periodically back up to the server to auth the user, why use the JWT in the first place?

It's so that if the JWT is stolen in transit, the thief only has access to the token for a shorter period of time. This is why they should expire quickly. Whether or not you think that matters, is not up for debate. That's how it is.

Re: JSON Web Tokens vs. Sessions

#118

Post by erpellan »

yxhuvud wrote: post #114
wtbob wrote: post #102

Earlier quoted context omitted.

Ummm, every browser for decades has supported URL parameters. I can't believe that IE breaks with them. Yes, large URLs are an issue, but not with search engines & access tokens, since search engines shouldn't ever see access tokens. A JWT should be lightweight — if it's big, then it's wrong.

There are length restrictions for get parameters in older browsers.

Up to 2000 characters is generally considered fine.

Re: JSON Web Tokens vs. Sessions

#119

Post by mschuster91 »

wtbob wrote: post #102
mschuster91 wrote: post #54

Earlier quoted context omitted.

> You can include a JWT as an access_token URL parameter, which works in a GET: Only works with IE > 11, and even IE 11 breaks down sometimes. Also, search engines choke on large URLs, see http://stackoverflow.com/a/417184/1933738

Ummm, every browser for decades has supported URL parameters. I can't believe that IE breaks with them. Yes, large URLs are an issue, but not with search engines & access tokens, since search engines shouldn't ever see access tokens. A JWT should be lightweight — if it's big, then it's wrong.

> but not with search engines & access tokens, since search engines shouldn't ever see access tokens

It's like with the PHPSESSID URL parameter before cookie support was widespread. You can very well attach a session to a search-engine bot, and there are explicit hints for appdevs to do so.

You have to pass the tokens somehow, and search engines usually don't run JS.

> A JWT should be lightweight — if it's big, then it's wrong.

A JWT should replace sessions, and I have seen megabyte-sized sesion files on servers. People put an awful lot of stuff into sessions. Especially if application state is contained in the session. Oh, and if your application e.g. stores paths to files in the session and you switch 1:1 to JWT, you will leak server information to the client, which is a security hole.

Re: JSON Web Tokens vs. Sessions

#120

Post by madeofpalk »

moyok wrote: post #108
madeofpalk wrote: post #103

Earlier quoted context omitted.

> the client uses the refresh token to get a new JWT What's the point of using the JWT then? If the refresh token lasts for longer than the JWT, and you need to send it periodically back up to the server to auth the user, why use the JWT in the first place?

The point is that it would reduce the DB/cache load, as the refresh token would need to be verified once in a few minutes or so as opposed to verifying it for every request. Regular requests could be authenticated in the CPU itself without having to go through to the DB/cache layer. This means lower latency and reduced load on the DB/cache.

...then make the JWT last as long as the refresh token.
Post reply on HN