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

51–60 of 159 posts

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

#51

Post by hn_throwaway_99 »

KPGv2 wrote: post #48
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…

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

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

#52

Post by unscaled »

gerdesj wrote: post #20
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…

A JWT can include claims - that's the difference: JWTs are a bit more complicated data structure out of the box. You can do authN and authZ in one go. You can do it all via individual browser cookies but it will be complicated. However you can dump session cookies to a database and then you can do claims locally on the server and use that cookie to tie it all together. So I think you can do it either way. JWTs are mu…

Everything can include "claims". Claims are just fields in a JSON object. If you're using your own token format which is based on Libsodium's secret box, you can just do `secretbox_seal(secret_key, json_encode(claims))`. It's a no-brainer one liner. You can even use MessagePack or protocol buffers instead of JSON and save a little bit on the token size.

JWT might do other things for you, like standardizing how to deal with key rotation (using the "kid" claim and JWKs discovery urls), or tying a bearer token to a PoP structure (DPoP), but that's all about standardization. And as a standard JWT is too flexible and ambiguous. There are better proposed standards out there, and for most of the thing JWT is used for (non-interoperable access tokens) it's an overkill.

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

#53

Post by paulddraper »

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…

I think you have a narrow view.

For example, a magic link sent via email can have a substantial validity duration.

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

#54

Post by ithkuil »

paulddraper wrote: post #53
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…

I think you have a narrow view. For example, a magic link sent via email can have a substantial validity duration.

Yes but generally magic links are only used for authentication. So if you delete or downgrade the principal whoever uses that magic link to authenticate can only perform the operations that are associated to the principal and the check is performed after the magic link is verified, unless the magic link also used to carry auth claims

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

#55

Post by kgeist »

marifjeren wrote: post #12

Love JWTs but I wish there was a better standard for conveying detailed and compact authorization information, for systems requiring enforcement of complex authorization rules. We experimented once with trying to put permissions on a JWT (more complex than your popular scopes) but that makes them grow quickly. And we experimented with putting role information on JWTs but that results in re-centralization of logic. Ma…

>We experimented once with trying to put permissions on a JWT (more complex than your popular scopes) but that makes them grow quickly.

We solved it by simply using bitmasks.

Say, you want to encode an access rule "allows reading from Calendar objects". The typical CRUD actions can be encoded with 4 bits. For example, all bits are zero => no access. The first bit is 1 => can create. The second bit is 1 => can read. Etc.

Then, say, if your system has 32 different types of objects, you can say that, "position 13 encodes for calendars". So you get 32*4 = 128 bits, i.e. just 16 bytes to encode information about CRUD rules for 32 different types of objects.

Sure it sounds complicated but if you move it to a library, you stop thinking about it.

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

#56

Post by pbreit »

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?

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

#57

Post by unscaled »

JimDabell wrote: post #35
francislavoie wrote: post #23

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

I believe OAuth doesn’t require JWT (just an opaque token, which in practice is often JWT), but OpenID Connect – which is based on OAuth – does require JWT.

Some optional OAuth extension RFCs do depend on JWT, e.g. Profile for OAuth 2.0 Access Tokens (RFC 9068) OAuth 2.0 Demonstrating Proof of Possession (DPoP) (RFC 9449, JWT-Secured Authorization Request (JAR) (RFC 9101). Core OAuth 2.0 does not enforce supporting JWT anywhere, but due to the influence of OpenID Connect there are more and more OAuth use cases that require JWT if you want to follow standards beyond the core OAuth RFCs (6749 and 6750).

The closest OAuth gets to mandating JWT is with client authentication and proof-of-possession. The OAuth Best Current Practices RFC (9700) recommends using asymmetric JWT for client authentication in case you cannot use Mutual TLS (which is usually the case). This recommendation will probably be rolled into the new OAuth 2.1 standard (it is included in the draft). OAuth 2.1 also mentions the JWT-based DPoP as one of the two recommended methods for implementing sender-constrained access tokens (the other one is Mutual TLS again).

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

#58

Post by vintermann »

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…

> 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 value store (really just key store). When someone manually invalidates a token, push it in, with the expiry date is has anyway.

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

#59

Post by detaro »

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?

yes, 100%
Post reply on HN