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

71–80 of 159 posts

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

#71

Post by p_l »

hn_throwaway_99 wrote: post #51
KPGv2 wrote: post #48

Earlier quoted context omitted.

[flagged]

I don't understand why you seem to think JWTs can't be used for authorization, and the fact that you denigrate this as a "puppynoob" approach is telling, but not necessarily in the way you think it is. Many large systems with millions of users (e.g. Google's Firebase) store user claims in the token, and that can (and is) used to validate permissions.

JWT can be used to store permission bits, but didn't it properly is very complex topic and usually works well only as "subsetting of claimed userid permission set" or "short lived token to be passed to third party to perform an action on behalf of".

One can do also quite complex system based on taking multiple claims as a whole plus signature, but that's taste in my experience other than stuffing user info into token

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

#73

Post by formerly_proven »

pbreit wrote: post #56
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…

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

Bearer token just means whoever has the token string has the associated capability - like bearer bonds.

Unlike e.g. challenge-response or signature authentication.

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

#74

Post by formerly_proven »

hdjrudni wrote: post #17

Every time I want to use a JWT, it seems like it's the suboptimal choice, so I've never found a genuine use case for them. Most recently, I wanted to implement 2FA w/ TOTP. I figure I'll use 1 cookie for the session, and another cookie as a TOTP bypass. If the user doesn't have a 2FA bypass cookie, then they have to complete the 2FA challenge. Great, so user submits username & password like normal, if they pass but d…

> I don't know, what's the use-case? Server-server interaction? Then they still need to share a key to validate the JWT. And probably all but the user-facing server doesn't need to be exposed to public internet anyway so why the hoopla adding JWT?

JWTs across servers are typically used with signatures, not in HMAC mode (so no globally shared HMAC keys). Then the issuer simply exposes a JWKS endpoint for downstream consumers (so no additional maintenance to distribute public keys).

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

#75

Post by akoboldfrying »

hn_throwaway_99 wrote: post #45
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…

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

This seems like about the best that can be done (well, you could go full Bloom filter to squeeze that revocation list size down even further), but it does seem vulnerable to DoS: Create 10000 accounts and log them all out at the same time to force the server into the slow PostgreSQL mode.

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

#77

Post by Zamicol »

francislavoie wrote: post #23

Paseto is better https://paseto.io/ , but unfortunately OAuth forces the usage of JWT.

{ "pay": { "msg": "There are also other options.", "alg": "ES256", "iat": 1748248973, "tmb": "9PcBWntvjAktwfiPp8WxgOyQOwc1h6Lo1UnB_gkWXKk", "typ": "cyphr.me/msg/create" }, "sig": "sHyMrykhsta5etjqH1e5oho0EpEs2FrblQ0DFHQo0aMgKd2V__SQ2Fl2EOSKt8wl65iLmKgIaMVEgCmhtvbUcg" }

Verify: https://cozejson.com

Spec: https://github.com/Cyphrme/Coze

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

#78

Post by formerly_proven »

gerdesj wrote: post #11
slt2021 wrote: post #9

Earlier quoted context omitted.

you cant generally reuse cookies across domains, because browser controls which domain receive which cookie. Also cookies are not cryptographically signed and thus easily forgeable by the client/browser. JWTs on the other hand allow to be used across domain, so that you can use JWT issued by your IDP on one domain, to be trusted on another domain. crypto signature helps in verifying integrity of data. sessions are us…

"Also cookies are not cryptographically signed and thus easily forgeable by the client/browser." My Apache webby thingies quite happily dole out encrypted cookies: https://httpd.apache.org/docs/2.4/mod/mod_session_crypto.htm... Your notes on cross site issues are also described there. JWTs are mutually shared secret passable with nobs on - you can store loads of data in them. Cookies are more one shot and one piece o…

Encryption generally doesn’t provide authentication, so I wouldn’t be surprised if that Apache module allows a user to flip is_admin=0 to 1 because the encryption is sufficiently malleable to do that. Especially because that page mentions 3DES.

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

#79

Post by unscaled »

hn_throwaway_99 wrote: post #51
KPGv2 wrote: post #48

Earlier quoted context omitted.

[flagged]

I don't understand why you seem to think JWTs can't be used for authorization, and the fact that you denigrate this as a "puppynoob" approach is telling, but not necessarily in the way you think it is. Many large systems with millions of users (e.g. Google's Firebase) store user claims in the token, and that can (and is) used to validate permissions.

JWT is basically just a signed JSON container format (JWS) with a couple of standard claims and recommended verification procedures. They can be used as a component of an authorization system but they would just be a small component of that. I think the question should be whether JWT is a good fit to play a part in authorization?

If you just need to tack in a bunch of scopes which are configured per clients and are rarely changed, or if you need to track authentication method and time for sensitive operations ("amr" and "auth_time" claims in OIDC), JWT could probably do the job. But for more fine-grained RBAC (or any user-permission-based scheme), JWT is quite problematic.

For one, you will need to revoke the access token every time permissions change. On certain type of systems this could happen quite often (e.g. every time somebody shares a folder with you), and you don't want to constantly log the user out, so all clients would have to have logic to automatically refresh the access token (with a permission-less refresh token) on revocation.

The other option is pure bloat: The moment you go beyond a simple admin flag or a fixed set of roles, you're already on the expressway to a bloated 10kb token. In every system that support a technically unlimited amount of resources and roles, storing all ACLs in the token gets you very large tokens really fast.

Post reply on HN