It's amazing to me that the whole article glosses over issues around key storage for symmetrical encryption, not to mention now you have an O(n) liability issue with all of your readers.
I think the scenario they're envisioning is one where the server generates an object, and some time later, wants to make sure it's getting back an object that the server has previously generated. HTTP cookies are a good example of this. Anything where you'd reach for JWT is probably also this use case.
> his post is mostly about authenticating consumers to an API. ... you’re trying to differentiate between a legitimate user and an attacker, usually by getting the legitimate user to prove that they know a credential that the attacker doesn’t.
The recipient of the API key doesn't need to verify their object. There's no attack from being able to give someone a fake API key - any attacker in a position to modify the API key in transit, which would just be a DoS, is also in a position to drop the connection, which is also a DoS. Such an attacker is probably also in a position to steal the API key silently, which is a bigger problem. (If a client is really curious whether they have a valid API key, they can just make an API call with it and see if it works, they still don't need to actually check the signature.)
I don’t think that’s a fair assumption. Google IAP puts JWTs in headers to attest the end user’s identity in a way you can’t just forge from inside the firewall. Other use cases have you obtain a JWT from a dedicated auth service, maybe even a 3rd party provider, so that other random services don’t have to know about passwords and 2FA. In both cases it would be prohibitively expensive to call back to the auth service to verify each token. The point of using a standard like JWT is to make it intelligible in other codebases, otherwise you could make your own format and serialization.
+1 on this. With asymmetric signing, you don't have to spread a secret far and wide. You could go a step farther with client certs, but still would need a more heavy management interface and a CA setup against your applications which means quite a bit more complexity.
