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

111–120 of 159 posts

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

#111

Post by mooreds »

fifticon wrote: post #66
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 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.

There are two in-use RFCs to make compromised tokens much harder to use by attackers. Neither use IP addresses, but both bind the token to the client using some form of cryptography.

RFC 8705 section 3[0], binds tokens by adding a signature of a client certificate presented to the server doing authentication. Then any server receiving that token can check to see that the client certificate presented is the same (strictly speaking, hashes to the same value). This works great if you have client certs everywhere and can handle provisioning and revoking them.

RFC 9449[1] is a more recent one that uses cryptographic primitives in the client to create proof of private key possessions. From the spec:

> The main data structure introduced by this specification is a DPoP proof JWT that is sent as a header in an HTTP request, as described in detail below. A client uses a DPoP proof JWT to prove the possession of a private key corresponding to a certain public key.

These standards are robust ways to ensure a client presenting a token is the client who obtained it.

Note that both depend on other secrets (client cert, private key) being kept secure.

0: https://datatracker.ietf.org/doc/html/rfc8705

1: https://datatracker.ietf.org/doc/html/rfc9449

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

#112

Post by bandoti »

mattmanser wrote: post #105
the_duke wrote: post #47

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 important to consider that JWT is a series of specs and folks can choose to use any of them to suit their needs.

In fact, it can be used to create simple tokens—even if you store them in a database in a traditional authentication sense.

But it is also helpful to be able to use OIDC, for example, with continuous delivery workflows to authenticate code for deployment. These use JWT and it works quite well I think.

Note: technically JWT is only one of the specs so it’s not exactly correct how I’m referring to it, but I think of them collectively as JWT. :)

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

#113

Post by mooreds »

francislavoie wrote: post #23

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

> OAuth forces the usage of JWT.

OAuth doesn't, OIDC does for the ID token[0]. OAuth, at least the inital RFCs, were released 3 years before JWT was defined. But many extensions of OAuth do require or support JWTs.

Either way, I'm just not sure the demand is there.

My employer has had an open issue for Pasteo[1] for years but hasn't seen much community support. Some other interesting comments here[2]. Looks like most of the implementations[3] are libraries rather than standalone auth servers.

0: https://openid.net/specs/openid-connect-core-1_0.html#IDToke...

1: https://github.com/fusionAuth/fusionauth-issues/issues/773

2: https://www.reddit.com/r/KeyCloak/comments/1e2h5w7/is_paseto...

3: https://paseto.io/

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

#114

Post by mooreds »

Here's an interesting video from an identity conference a few years ago. The speaker is Brian Campbell who was one of the JWT spec authors.

https://www.youtube.com/watch?v=IgKRGS6cQWw

Here's the video description:

> JWT is an IETF standard security token format that, due to perceived simplicity and widespread library availability, has been extremely popular in recent years. Despite that popularity (or maybe, in part, because of it), JWT has been heavily derided by reputable people in information security ("horrible standard", "RFC was made by monkeys", "Internet’s worst cryptography standard", "JWT is a disaster ... amazing how bad it is", "simplistic, complicated, and unsafe all at the same time", and "almost impossible to build a secure JWT library" ...give just a taste of the sentiment).

> The criticism has been substantiated and amplified by a steady stream of public vulnerabilities in libraries and deployments. Indeed there have been serious and legitimate security problems with JWT and many of them can be attributed directly to fundamental flaws in the specification itself that allowed, or even encouraged, such implementation mistakes. But is JWT irredeemably flawed? This session will endeavor to take a hard look at that very question (complete with the presenter's own sense of inadequacy and fear of culpability in JWT's flaws) with a review/overview of JWT fundamentals and a pragmatic look at each of the most common and/or biting criticisms and associated real-world vulnerabilities.

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

#115

Post by hirsin »

kgeist wrote: post #55
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. E…

That works as long as you have no distinctions between objects of a type. _Which_ calendar can they edit? All of them?

Putting all the repos you can access into a token is a request we get sometimes. It would be... Difficult.

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

#116

Post by hirsin »

Zamicol wrote: post #77
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

Hm, I wonder how the double sig problem that SAML would run into will work here. What happens if someone adds an extra sig object there?

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

#117

Post by deeringc »

90s_dev wrote: post #7
vrosas wrote: post #4

Earlier quoted context omitted.

If you go back and search hacker news for any article involving JWTs or OAuth you’ll find hundreds of comments of circular arguments over what a JWT is and is not. People never seem to be able to separate the two.

I still don't really understand them. The last time I used them was for a client probably in 2016 or 2018, and I forgot everything I learned about them. But they have an RFC so that's pretty cool.

JSON Web Tokens are part of the JSON Object Signing and Encryption (JOSE) family of standards which are really just containers for cryptographic primitives in a web-friendly representation. Most people are aware of JWS (signed payloads) but there are also JWE (encrypted payloads) and JWK (key payloads). If you're building any sort of cryptographic system that needs to represent encrypted/signed values or keys, you can use JOSE to represent these primitives without having to reinvent the wheel. By far the biggest use of JOSE is in authentication systems where JWS are used as signed bearer tokens but that's just one application and there are many others. They arent perfect, but they filled an important gap when they were created and made it much easier to deal with crypto at an application layer compared with all of hte binary formats that are used in things like TLS.

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

#118

Post by brok3nmachine »

unscaled wrote: post #100
pwlb wrote: post #69

Earlier quoted context omitted.

You may have a look at this (still a Draft): https://datatracker.ietf.org/doc/draft-ietf-oauth-status-lis...

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…

For this reason, I use a LaunchDarkly config flag for the revocation list. Updates to the config are pushed to all LD clients in near real time.

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

#119

Post by paulddraper »

ithkuil wrote: post #54
paulddraper wrote: post #53

Earlier quoted context omitted.

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

Yes, up-to-date permissions require centralized consistency.

My point is…JWT can be used in a number of contexts.

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

#120

Post by lyu07282 »

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…

I use JWT and a half dozen other standards, not by choice though, I wished I could do what you suggest it would simplify everything a ton, but I'm not going to roll my own multi-org/SSO/2FA auth platform. Needing those auth features is what made me use these standards not because my app is big, it's not it's tiny.
Post reply on HN