Ten Years of JSON Web Token and Preparing for the Future

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 mutually authenticated (shared secret) but cookies are not.

Long before JWT existed, if you wanted to pass some trusted data through an untrusted channel, you would make a payload with an expiry, encrypt or sign it with your secret key, then send it. However, you would need to make up your own way to send this info. For example, if this were a website, you might dump the signed/encrypted payload into several form fields and upon receiving it back, you would verify that it was signed with your key.

Now that JWT exists, there is a standard way to do it so you don’t have to write the same boring code a bunch of times in different languages. You just have one string you pass in one field and if you tell someone else that it’s a JWT, they know how to parse it. You don’t have to document your own special way anymore.

At the end of the day, it’s just a standard for that specific problem that didn’t have a standard solution before. If passing data like that is not a problem for your use case, then you don’t need the tool.

To use your Protobuf example, there was a time before Protobuf or tools like it existed. I can tell you that writing the exact same protocol code by hand in Java, PHP, and Python is absolute tedious work. But if it never came up that you had to write your own protocol, you neither know the pain of doing it manually nor the pleasure of using Protobuf, and that’s fine.

In your scenario you could still apply additional protections to a user id after detecting X attempts of sending a forged JWT. At least you could alert on JWTs that arrive with invalid signatures. Or you could put a 2FA challenge key inside the JWT, just use the JWT as a container to hold the information you would have shared with the client anyway.

I agree that JWTs don't really do anything more than a cookie couldn't already do, but I think the use case is for apps, not web browsers. In particular apps that do raw HTTP API calls and do not implement a cookie jar. And then because most companies do "app first development", we end up having to support JWT in the web browser too, manually putting it into localstorage or the application state, instead of just leveraging the cookie jar that was already there.

We just recently had to implement an SSO solution using JWT because the platform only gave out JWTs, so we ended up putting the JWT inside an encrypted HttpOnly cookie. Seemed a bit like a hat-on-a-hat, but eh.

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 web devs insisted on JWT and cough "forgot" about the auth bearer bit in the header because their API didn't use it. I ended up amending and recompiling an Apache module for that but to be fair, they will support it in the next version so I can revert my changes. A few db lookups in the Apache proxy JWT module I'm using and you have your claims.

On the front of that lot you have Apache session cookies generated when auth succeeds against a PrivacyIDEA instance - ie MFA.

I suppose we have cookies for authN and JWT for authZ. Cookies could do both and apart from session I'm not too familiar but it looks like claims would require multiple cookies where JWT does it all in one.

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 usually tied to a single backend/application server. Its hard to reuse a session data across different apps.

JWTs on the other hand allow sharing session data across different app servers/microservices.

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.

Oh yeah the token grows in length very quickly, we also tried using it 5 years ago to pass in roles to the client and ended up with many issues

Authorization is really not a generally solvable problem. Every large system ends up having its quirks.

Attempting to generalize it ends up in pain, suffering, and AWS IAM.

I fail to see how it's better, except for hand-waving about potential crypto attacks?

It seems to be a NIH-ed serialization format with hard-coded ciphersuits. It doesn't seem to support use-cases like delegation and claims.

> JWTs are a vanity project of the JS community

JWTs are standardized (RFC 7519) and used outside the JS ecosystem. Not a vanity project

Though often overused and poorly misunderstood where simpler and more secure methods would suffice.

Did you mean cert exchange, because keys are just a very long password, but certs carry actual information about the holder (err, I guess pedantically of the holder with the key)