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.

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.

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.

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.

You might want to check out Biscuit:

> Biscuit is an authorization token with decentralized verification, offline attenuation and strong security policy enforcement based on a logic language

— https://www.biscuitsec.org

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)

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

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.

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.

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.

> what's the use-case?

The use-case I always remember people presenting for JWTs was mostly part of the "serverless" fad/hype.

The theory was presented like this: If you use a JWT your application logic can be stateless when it comes to authentication; So you don't need to load user info from a session database/kv store, it's right there in the request...

The only way that makes any sense to me, is if your application has zero storage of its own: it's all remote APIs/services, including your authentication source. I'm sure there are some applications like that, but I find it hard to believe that's how/why it's used most of the time.

Never underestimate this industry's ability to get obsessed with the new shiny.

I had an eye opening experience many years ago with a junior dev (I was significantly more experienced than he was then, but wouldn't have called myself "senior" at the time).

He had written an internal tool for the agency we both worked for/through. I don't recall the exact specifics, but I remember the accountant was involved somewhat, and it was a fairly basic CRUD-y PHP/MySQL app. Nothing to write home about, but it worked fine.

At some point he had an issue getting his php/mysql environment configured (I guess on a new laptop?) - this was before the time of Docker; Vagrant was likely already a thing but he wasn't using it.

From what he explained afterwards I believe it was just the extremely common issue that connecting to "localhost" causes the mysql client to attempt a socket connection, and the default socket location provided in php isn't always correct.

As I said, I heard about this after he'd decided that connection issue (with an app that had already been working well enough to show off to powers-that-be and get approval to spend more paid time on it) was enough to warrant re-writing the entire thing to use MongoDB.

As I said: never underestimate this industry's ability to get obsessed with the new shiny.

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.

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.

Yes, it’s linked using the standard autodiscovery rel=alternate meta element. You should be able to just paste the site URL into whichever feed reader you use to subscribe.