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

Stop using JSON Web Tokens for user sessions

ds-security.com

Post reply on HN
Print view View original

41–50 of 145 posts

Re: Stop using JSON Web Tokens for user sessions

#41

Post by pests »

kaoD wrote: post #36
sseagull wrote: post #33

Earlier quoted context omitted.

I am no JWT expert, but I have found them useful for APIs rather than web apps accessed from the browser. If the user is expected to use a programming language and hit the API many times a second, then even a short expiration and moderate refresh really help (might fully authenticate every 5 mins, which could be thousands of requests for some APIs).

But again, what's the difference between that and just having a moderately-long access token if you'll still be handing out access tokens for the lifetime of the refresh token?

> for the lifetime of the refresh token

Not guaranteed for the lifetime of refresh tokens, which is the case for access tokens.

> whats the difference?

A 5 min access token is valid for 5 minutes. A 5 minute refresh token can be revoked before its even used.

Re: Stop using JSON Web Tokens for user sessions

#42

Post by kaoD »

growse wrote: post #38
kaoD wrote: post #28

Earlier quoted context omitted.

But I already pointed that out in my question. You didn't address my actual concern.

The access tokens go everywhere , to all services and are much more likely to be accidentally leaked / misappropriated. Refresh tokens are only used when talking (infrequently) to the access token minting service, so the scope of use is much much narrower.

So if I get this correctly, this is mostly useful for microservices and would be kinda pointless for a monolithic architecture?

Re: Stop using JSON Web Tokens for user sessions

#44

Post by sseagull »

kaoD wrote: post #36
sseagull wrote: post #33

Earlier quoted context omitted.

I am no JWT expert, but I have found them useful for APIs rather than web apps accessed from the browser. If the user is expected to use a programming language and hit the API many times a second, then even a short expiration and moderate refresh really help (might fully authenticate every 5 mins, which could be thousands of requests for some APIs).

But again, what's the difference between that and just having a moderately-long access token if you'll still be handing out access tokens for the lifetime of the refresh token?

Another comment mentioned it, but:

1. You can check for user changes when the refresh token is used and a new access token is requested (user deleted, permissions changed, access revoked)

2. Refreshes can go to a different endpoint, whereas access tokens could be used with services that don’t even have access to user auth services.

Edit: There is something to be said for ditching the refresh token and just re-authenticating when the access token expires. The benefit is that you don’t need to store the username/password in the client code to re-auth, and you might avoid some relatively expensive password checking on the server, but that is probably pretty minor.

Re: Stop using JSON Web Tokens for user sessions

#45

Post by jFriedensreich »

i really don’t understand how the article assumes jwt s are not stored in http only cookies. Jwts are an encoding method you can use them to implement a wide array of usecase and if they are used for sessions of course the security best practices for session cookies have to be met, that has nothing to do with jwts except that they require special thought compared to server side sessions when it comes to things like invalidation.

Re: Stop using JSON Web Tokens for user sessions

#46

Post by vbezhenar »

kaoD wrote: post #20

As a side question (or rather, what I expected the central point of the article to be instead): how are you supposed to actually use JWT? The point of JWT vs opaque tokens is that you can just inspect the token itself to derive permissions without hitting any sessions in DB, right? This means we need a short-lived access token (5 min or so?) so that sessions are revoked in a reasonable time if the token is stolen som…

I might be wrong about it, but my understanding is as follows:

You're getting refresh token using credentials (e.g. login/password). Refresh token is long-lived and basically allows you to use service without typing login/password every 5 minutes. How much refresh token should live depends on your security requirements to how long user can user your service without typing his password.

You're getting access token using refresh token. This allows server to check whether you've been banned or something like that. If you encode access permissions into access token, it also allows to adjust those permissions. So your access token lifetime is a balance between performance and security.

If your API already uses some kind of service key, then refresh token does not make much sense (may be it does to provide uniform implementation for web clients and service clients, but not from security perspective).

My opinion is that all those things are more complicated than necessary. You could use the same token both for access and refresh purposes (if token is outdated, check it using database and return new token, then client will use new token for subsequent requests).

Re: Stop using JSON Web Tokens for user sessions

#47

Post by muldvarp »

kahnclusions wrote: post #25
theropost wrote: post #10

Earlier quoted context omitted.

But aren't HTTPonly coookies stored in a SQLite db, and have no password attached in Firefox or Chrome?

Both cookies and localStorage are usually stored in an SQLite db… localStorage is totally accessible to any JavaScript running on the page, so your session can be completely hijacked and used later.

> so all it takes is a little injected script

If you can inject javascript, it's game over anyway.

> HTTPOnly cookies are safe from XSS attacks.

No, you can still do pretty much anything that cookie enables you to do. You just can't get the actual cookie string.

Re: Stop using JSON Web Tokens for user sessions

#48

Post by [deleted] »

kaoD wrote: post #36
sseagull wrote: post #33

Earlier quoted context omitted.

I am no JWT expert, but I have found them useful for APIs rather than web apps accessed from the browser. If the user is expected to use a programming language and hit the API many times a second, then even a short expiration and moderate refresh really help (might fully authenticate every 5 mins, which could be thousands of requests for some APIs).

But again, what's the difference between that and just having a moderately-long access token if you'll still be handing out access tokens for the lifetime of the refresh token?

[deleted]

Re: Stop using JSON Web Tokens for user sessions

#49

Post by drekembe »

jinnko wrote: post #17
onethought wrote: post #4

TLDR store session things in cookies with httponly set. Basically nothing to do with jwts. More to do with xss

And set the SameSite attribute to strict to prevent CSRF

Wouldn't SameSite=Lax work just as well to prevent CSRF? It prevents things like malicious forms and image links from other sites.

Re: Stop using JSON Web Tokens for user sessions

#50

Post by growse »

kaoD wrote: post #42
growse wrote: post #38

Earlier quoted context omitted.

The access tokens go everywhere , to all services and are much more likely to be accidentally leaked / misappropriated. Refresh tokens are only used when talking (infrequently) to the access token minting service, so the scope of use is much much narrower.

So if I get this correctly, this is mostly useful for microservices and would be kinda pointless for a monolithic architecture?

Not even necessarily microservers. If you want a common authentication system used by lots of disparate services, token based Auth is a reasonable approach.

If you've just got one service endpoint, it doesn't buy you very much. Just mint a session token and be done with it.

Post reply on HN