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

Ten years of JSON Web Token and preparing for the future

self-issued.info

Post reply on HN
Print view View original

151–159 of 159 posts

Re: Ten years of JSON Web Token and preparing for the future

#151

Post by paradox460 »

martinald wrote: post #41

The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…

You don't have to check the db every request. Just store a list of revoked tokens in a fast cache, like redis, with ttl longer than the longest token lifetime and reject/force reauth any token that matches

Re: Ten years of JSON Web Token and preparing for the future

#152

Post by nh2 »

unscaled wrote: post #108
methou wrote: post #15

JWTs are just too fat, and JS users often forgets encoding is not encryption. I've seen some news site trackers send JWT in url/header to some 3rd party tracker. Content is no surprise, my full name, and email address, violates its own privacy policy. Otherwise it's very open and handy, from inspecting a jwt token I can learn a lot about the architectural design of many sites.

tptacek's survey was already mentioned here, but I think it should be more famous. https://fly.io/blog/api-tokens-a-tedious-survey Unfortunately, it seems like 99% of the industry decides which token to use based on Medium articles, LLM responses or how many unmaintained packages that implement this thing they can find on NPM. JWT is mostly used as an access token, but for the vast majority of use cases it's a bad fi…

> or make sure that the Session ID field is indexed with a hash-based index

Using a hash index instead of a btree isn't a 100% guaranteed solution because there may be craftable collisions (because e.g. postgres's index hash is not cryptographic) which cause fallback to linear comparison across the values inside the hash bucket:

https://dba.stackexchange.com/questions/285739/prevent-timin...

So hashing the ID before the DB lookup is better.

Re: Ten years of JSON Web Token and preparing for the future

#153

Post by bilater »

martinald wrote: post #149
bilater wrote: post #131

Earlier quoted context omitted.

Can you tell me of any instance where someone's auth needed to be revoked within 5 minutes and a delay was not acceptable? I think it's more of an imaginary 'five nines' engineering thing than real life.

Firstly I don't think most people who use JWTs use 5 min refreshes. But even assuming that - any collaboration software. Imagine you invite a user by mistake to an internal wiki, you don't really want them looking at the content for 5 minutes. Much better to be able to revoke instantly. Then you have anything that handles financial data. If you're a bank and you get a call that you have a fraudster taking over an acc…

fair these are good examples. still feel there is a better trade off than constant pings.

Re: Ten years of JSON Web Token and preparing for the future

#154

Post by cyberax »

francislavoie wrote: post #148
cyberax wrote: post #146

Earlier quoted context omitted.

The JWT spec can thus be fixed by changing the recommended set of primitives. No need to reinvent the wheel with custom serialization (that probably also has vulnerabilities when implemented by clueless people). You parade the alg=none vulnerability that has been fixed long ago as the reason to reinvent the world. It's simply not.

The spec is fundamentally flawed. The fixed spec would be a different spec, i.e. something like PASETO.

You keep repeating that. What is "fundamentally flawed"?

PASETO has exactly the same vulnerabilities. You can specify a different version, and a buggy implementation can misinterpret it. With PASETO, the algorithm selection is fully under the control of the attacker.

Re: Ten years of JSON Web Token and preparing for the future

#155

Post by unscaled »

motorest wrote: post #143
unscaled wrote: post #100

Earlier quoted context omitted.

I don't think status lists solve the requirement for near-realtime revocations. The statuslist itself has a TTL and does not get re-loaded until that TTL expires. This is practically similar to the common practice of having a stateful refresh token and a stateless access token. The statuslist "ttl" claim is equivalent to the "exp" claim of the access token in that regard, and it comes with the same tradeoffs. You can…

> The statuslist itself has a TTL (...) If you read the draft, the TTL is clearly specified as optional. > (...) and does not get re-loaded until that TTL expires. That is false. The draft clearly states that the optional TTL is intended to "specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved." > You can have a lower TTL for st…

In that case, when and how would you reload the statuslist?

Again, it doesn't matter if TTL and caching is optional, what matters is that this specification has NOTHING to do with a pub/sub-based or push-based mechanism as described by GGGP. This draft specifies a list that can be cached and/or refreshed periodically or on demand. This means that there will always be some specified refresh frequency and you cannot have near-real-time refreshes.

> There is also a practical limit to how frequently you refresh a token revocation list. Some organizations have a 5-10min tolerance period for basic, genera-purpose access tokens, and fall back to shorter-lived and even one-time access tokens for privileged operations. So if you have privileged operations being allowed when using long-lived tokens, your problem is not the revocation list.

That's totally cool. Some organizations are obviously happy with delayed revocations for non-sensitive operations, which they could easily achieve them with stateful refresh tokens, without the added complexity of revocation lists. Stateful and revokable refresh tokens are already supported by many OAuth 2.0 implementations such as Keycloak and Auth0[1]. All you have to do is to set the access token's TTL to 5-10 minutes and you'll get the same effect as you've described above. The performance characteristics may be worse, but many ap which are happy with delayed revocation are happy with this simple solution.

Unfortunately, there are many products where immediate revocation is required. For instance, administrative dashboards and consoles where most operations are sensitive. You can force token validity check through an API call for all operations, but that makes stateless access tokens useless.

What the original post above proposed is a common pattern[2] that lets you have the performance characteristics (zero extra latency) of stateless tokens together with the security characteristics of a stateful access token (revocation is registered in near-real-time, usually less than 10 seconds). This approach is supported by WSO2[3], for instance. The statuslist spec does nothing to standardize this approach.

[1] https://auth0.com/docs/secure/tokens/refresh-tokens/revoke-r...

[2] See "Decentralized approach" in https://dzone.com/articles/jwt-token-revocation

[3] https://mg.docs.wso2.com/en/latest/concepts/revoked-tokens/#...

Re: Ten years of JSON Web Token and preparing for the future

#156

Post by nextaccountic »

the_duke wrote: post #47
martinald wrote: post #41

The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…

Active user logouts, deletions, permission changes are rare, so the size of revocations lists is extremely small compared to number of tokens in existence. You can keep revocations in a very fast lookup system (eg broadcasts + in-memory store), combined with reasonably short token renewals, like 5-60 minutes. Massively cuts down the number of token validity checks, and makes the system tolerant to downtimes of the au…

> makes the system tolerant to downtimes of the auth system

You mean the system that handles revocations? If so, your own system will be vulnerable if you continue to do business as usual while it's down

Re: Ten years of JSON Web Token and preparing for the future

#157

Post by motorest »

unscaled wrote: post #155
motorest wrote: post #143

Earlier quoted context omitted.

> The statuslist itself has a TTL (...) If you read the draft, the TTL is clearly specified as optional. > (...) and does not get re-loaded until that TTL expires. That is false. The draft clearly states that the optional TTL is intended to "specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved." > You can have a lower TTL for st…

In that case, when and how would you reload the statuslist? Again, it doesn't matter if TTL and caching is optional, what matters is that this specification has NOTHING to do with a pub/sub-based or push-based mechanism as described by GGGP. This draft specifies a list that can be cached and/or refreshed periodically or on demand. This means that there will always be some specified refresh frequency and you cannot ha…

> In that case, when and how would you reload the statuslist?

It only depends on your own requirements. You can easily implement pull-based or push-based approaches if they suit your needs. I know some companies enforce a 10min tolerance on revoked access tokens, and yet some resource servers poll them at a much higher frequency.

> Again, it doesn't matter if TTL and caching is optional (...)

I agree, it doesn't. TTL is not relevant at all. If you go for a pull-based approach, you pick the refresh strategy that suits your needs. TTL means nothing if it's longer than your refresh periods.

> This draft specifies a list that can be cached and/or refreshed periodically or on demand. This means that there will always be some specified refresh frequency and you cannot have near-real-time refreshes.

Yes. You know what it makes sense for you. It's not for the standard to specify the max frequency. I mean, do you think the spec specify max expiry periods for tokens?

Try to think about the problem. What would you do if the standard somehow specified a TTL and it was greater than your personal needs?

Re: Ten years of JSON Web Token and preparing for the future

#158

Post by alexdbird »

hn_throwaway_99 wrote: post #95
fifticon wrote: post #66

Earlier quoted context omitted.

I have a random idea regarding compromised tokens, which may not hold water. What if you put things like the client's IP address in the token? Then the server can reject (and mark for compromise) as soon as they receive any request from a different ip address? I realise this will also invalidate people who somehow roam between ip addressses, say DHCP/wireless in a larger building.

Client IP addresses change a lot more than you think, especially on mobile networks.

Yup. I worked for a media company that made IP part of the access token for media playback. An absolute PITA for the mobile app, and made (reliable) background downloads impossible on iOS. A bad idea. They went out of business.

Re: Ten years of JSON Web Token and preparing for the future

#159

Post by zaphar »

konha wrote: post #107
mattmanser wrote: post #105

Earlier quoted context omitted.

This makes it sound like you've only worked in an extremely narrow domain. It's not rare, it happens constantly in enterprise software, project managemment software, anything where you have collaboration. What is so frustrating about tech like JWTs is that it fits the fairly rare, high profile, websites like Reddit, netflix, etc. but doesn't fit ANYTHING else. Everyone else wants immediate revocation of rights, not w…

> It's not rare, it happens constantly in enterprise software, project managemment software, anything where you have collaboration The number of revoked tokens compared to all active tokens should still be tiny in those systems, wouldn’t you agree? > Everyone else wants immediate revocation of rights, not waiting for a token to expire. With a revocation list you can still have that. Once you propagated your revocatio…

The size of the revocation list is irrelevant. As soon as you have to do a call to get the revocation list you might as well just include the rest of it in the call as well.
Post reply on HN