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

101–110 of 173 posts

Re: JSON Web Tokens vs. Sessions

#101

Post by areed »

joepie91_ wrote: post #83
hharnisch wrote: post #35

Earlier quoted context omitted.

On another note I've been working on a service that generates expirable/refreshable JWTs. Its a good way to start trying them out https://github.com/hharnisc/auth-service

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

Re: JSON Web Tokens vs. Sessions

#102

Post by wtbob »

mschuster91 wrote: post #54
wtbob wrote: post #33

Earlier quoted context omitted.

> There's standard ways to include the JWT in the request body, like form encoding, but that doesn't work for GET requests, so in practice everyone uses the Authorization header. You can include a JWT as an access_token URL parameter, which works in a GET: https://foo.invalid/bar?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RM…

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

Re: JSON Web Tokens vs. Sessions

#103

Post by madeofpalk »

moyok wrote: post #21
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…

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?

Re: JSON Web Tokens vs. Sessions

#104

Post by pkulak »

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…

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 if we could get around that massive traffic pinch point. So, we create crypto tokens that can be validated by every service without the need to make a network call. As a compromise, we make this new token expire in an hour so that the _client_ needs to validate their refresh token every hour and all our services are freed of from ever directly calling the auth service. Sure, this means that when you log out you're not really logged out for up to an hour, but it's all tradeoffs.

Re: JSON Web Tokens vs. Sessions

#105

Post by 3pt14159 »

moyok wrote: post #41
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…

I have personally experienced the security disadvantage you mentioned. I used my Google login to sign into an email client. I immediately realised that the app was going to store all of my email data in their private servers. I quickly went over to the Google dashboard and deauthorised the app, relieved that they would only have been able to get my first few mails in this time. But the app retained access to my email…

> despite this disadvantage some applications just cannot afford the load of every single request touching the DB or cache.

Disagree. This is one of the simplest things alive to distribute. Split the query from the token do the query in the DB and the token lookup is effectively a distributed hash table lookup (assuming the token is, say, a UUID). Once the DB query comes back store the result pending the successful retrieval of the token.

What's difficult is handling something like millions of concurrent video downloads / uploads - not looking up tiny tokens.

Re: JSON Web Tokens vs. Sessions

#106

Post by stephenr »

I've had this "them: we should use JWT, it's easier to scale; me: the customer has 200 clients, they don't need to scale shit, sessions are fine" argument before, and honestly at this point I'm pretty convinced JWT isn't a replacement for session auth.

The one place I can see it might be useful, is when you need to give a third-party system some kind of access to your API, as an alternative to storing a secondary hashed field(s) for api keys.

Re: JSON Web Tokens vs. Sessions

#107

Post by kbar13 »

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?

jwt can be verified by the application without having to make a call to the auth service

Re: JSON Web Tokens vs. Sessions

#108

Post by moyok »

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?

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.

Re: JSON Web Tokens vs. Sessions

#109

Post by paulddraper »

3pt14159 wrote: post #105
moyok wrote: post #41

Earlier quoted context omitted.

I have personally experienced the security disadvantage you mentioned. I used my Google login to sign into an email client. I immediately realised that the app was going to store all of my email data in their private servers. I quickly went over to the Google dashboard and deauthorised the app, relieved that they would only have been able to get my first few mails in this time. But the app retained access to my email…

> despite this disadvantage some applications just cannot afford the load of every single request touching the DB or cache. Disagree. This is one of the simplest things alive to distribute. Split the query from the token do the query in the DB and the token lookup is effectively a distributed hash table lookup (assuming the token is, say, a UUID). Once the DB query comes back store the result pending the successful r…

tiny tokens, but needed for every single operation

Re: JSON Web Tokens vs. Sessions

#110

Post by tjbiddle »

nstart wrote: post #9

That last part where he talks about logging out being the responsibility of the client is rather key. Basically I can't invalidate the key from the server side. So if a user's account is compromised and they recover it on their mobile app for example, I can't sign the user out of everywhere else too. It's what has given me pause about jwt so far and has held me back from using it. I find the cookie is generally good…

I store a `login_count` in my User model. When searching for a user I `find_by_user_and_login_count`. The token they have has their current login_count in the claims. If I want to logout server side, I just update this value (Can be a random string if you'd rather it not be in increasing integer) and it will invalidate all tokens. When they logout client side, of course we can just clear the token from their memory. If they want to invalidate all tokens, then we have an API endpoint for that and it will logout from all devices.
Post reply on HN