Live data from Hacker News

Ten years of JSON Web Token and preparing for the future

self-issued.info

101–110 of 159 posts

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

#101
post #10

Earlier quoted context omitted.

Cookies are only controlled by the server but obviously can be negotiated for with a secret. JWTs have a mutual secret component built in and far cooler sounding ... stuff. So both ends have to trust the other and prove it with JWT and when cookies are in play, you takes your chances - you can use mutual TLS to get the same trust that JWT gives. I have a web app that I'm doing sysops for which ended up with both. The…

I use JWTs with RSA key pairs primarily. I tell the other service to make the pair and send me the public. I never see the private. Then I can verify all their tokens with the public key. This way I don’t have to worry about sharing the secret. It never leaves the other service.

Isn't that what OIDC/JWKS is? That also uses PKI to verify JWT with public keys.

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

#103
post #56

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…

If a token is not a JWT is it really a “Bearer” token?

"Bearer" and JWT are orthogonal. Tokens in other format or stateful formats can be bearer tokens, while JWTs can use non-bearer authentication methods. For instance, RFC 9449 (DPoP) describes an authentication method where you have to provide a PoP (based on JWS) in addition to an access token (which may or may not be JWT).

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

#104

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…

> 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 whatever else was in the claim there quickly. FWIW, I built a system previously that got around this "having to check the DB on every access to check for revocations" issue that wo…

Just seems like a lot of extra fiddly stuff to go wrong for monolithic apps. I get it if you have went all in on microservices as each "client" request can fan out to hundreds of requests, each requiring an auth check.

But still, I'm not sure that I've seen an auth/roles database that couldn't fit (at least) the important stuff itself in RAM itself fwiw. Even 1TB of RAM is relatively affordable (if you are not on the hyperscalers) and you could fit billions of users in that, which at least in theory means you can just check everything and not have another store to worry about.

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

#105

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…

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 waiting for a token to expire.

And yet we all have to suffer this subpar tech because someone wrote a blog post about it and a bunch of moronic software "architects" made it the only option. If you don't JWT somehow you're doing it wrong, even though it should in fact be an extremely niche way of doing Auth at scale.

Simple cookie based tokens were and still are a much better choice for many applications.

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

#106

Earlier quoted context omitted.

> 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 whatever else was in the claim there quickly. FWIW, I built a system previously that got around this "having to check the DB on every access to check for revocations" issue that wo…

> You only need to keep around a list of revocations for as long as your token expiry is. For example, if your token expiration is 30 mins, and you expire a user's tokens at noon, by 12:30 PM you can drop that revocation statement, because any tokens affected by that revocation would have expired anyway. And this sort of thing is basically what redis is for, right? Spin up a docker container, use it as a simple key v…

Might not even need to store the token itself just a piece of data that is contained in the claims to say the account is in a good state. Any number of tokens then can be issued and the validation step would ensure the claims is correct.

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

#107

Earlier quoted context omitted.

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…

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 revocation to all relying parties the token effectively expires early.

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

#108
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 fit. If you've got low traffic no strict multi-region deployment requirements, random IDs are the best approach for you. They are extremely lean and easy to revoke. It's pretty secure: the only common vulnerabilities I can think of with this approach are session fixation[1] and timing attacks[2]. Both attacks are preventable if you take just a few simple precautions:

1. Always generate 32-byte session IDs using a cryptographically secure random number generator on authentication. (Never re-use existing session IDs for new logins)

2. Either use a cryptographic hash (e.g. SHA-256 or Blake2b) of the session ID a the database field used when querying sessions or make sure that the Session ID field is indexed with a hash-based index (B-trees are susceptible to timing attacks).

In cases where you really cannot use Session IDs, your service is usually big enough and important enough to use custom Protobuf tokens even a more special-purpose format like Macaroons. These formats give can be far more compact and give you full control on designing for your needs. For instance, if you want flexible claims (with most of them standardized across your services), together with encryption, you can use a combination of Protobuf and a libsodium secret box envelope.

[1] https://owasp.org/www-community/attacks/Session_fixation

[2] e.g. https://github.com/advisories/GHSA-cvw2-xj8r-mjf7

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

#109

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 want to be able to revoke auth straight away if an account is compromised

It really depends on the system. In my experience, there are tons of apps that want to be able to revoke access but weigh that against transparent re-authentication. OIDC handles both nicely with:

* short access/id token lifetimes (seconds to minutes)

* regular transparent refreshes of those tokens (using a refresh token that is good for days to months)

This flexibility lets developers use the same technology for banks (with a shorter lifetime for both access/id tokens and refresh tokens) and consumer applications (with a short lifetime for access/id tokens and a longer lifetime for refresh tokens).

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

#110

Earlier quoted context omitted.

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…

Is there a proposed rfc for revocation lists?

https://datatracker.ietf.org/doc/html/rfc7009 handles generic revocation without specifying implementation details.

Some auth servers implement it. Keycloak does[0]. Auth0 doesn't as far as I can tell[1]. FusionAuth (my employer) has had it listed as a possible feature for years[2] but it never has had the community feedback to bubble it up to the top of our todo list.

0: https://www.keycloak.org/securing-apps/oidc-layers#_token_re...

1: https://auth0.com/docs/secure/tokens/revoke-tokens

2: https://github.com/fusionAuth/fusionauth-issues/issues/201

Post reply on HN