Hacker News Reader

Hacker News

Comment by cappie013 | Hacker News Reader

Parent Full thread

cappie013

Exactly what I was thinking while reading the article.

I'm using JWT for an API, and the server is choosing which algorithm to chose.

Really don't understand why a client should bypass server.

View on HN

You could even hit 2 birds with 1 stone by going with headerless JWTs (just strip the first segment).

Keeping the JWT format as-is is useful if you have signed (but not encrypted) tokens though; in a web browser you can use standard libraries to inspect the token and alter the UI based on a user's permissions (the final check is always the API's responsibility of course, but if there is no need to show the 'admin' link the client can do that).

If it isn't encrypted, the only thing the client needs to know is that it's base64 encoded in order to inspect it. You'd need the secret to verify the signing and you probably shouldn't have that on the client-side!

So I still think the header is superfluous even for this use case.

edit: in fact, the client needs to know that it's base64 encoded to even read the header in the first place.

Symmetric signing is not, by far, the only use case for JWTs. Asymmetric signing, and encryption, are also well-specified and supported.

Good point! It slipped my mind.

There's some value in the header. Google use it to store the keyid, which is pretty useful.

You can run into issues with headerless JWTs when you can't (or don't) guarantee the order of the header. Since the header is included in the signature of JWS objects, you must reattach a header that is exactly the same, and not just equivalent.

For example, both of these decoded headers are equivalent:

{ "alg": "HS256", "typ": "JWT" }

{ "typ": "JWT", "alg": "HS256" }

Obviously, these encode to two different values. If you reattach the wrong one, signature verification will fail.

Disclaimer: I maintain a Python JOSE library and have had to answer questions related to this on more than one occasion.

The question is: what if you change the algorithm on the server, and a user still has an old token.

Usually you don't care (as in will never happen), but on the off chance you do, you have to do 2 deploys, 1 to add the new thing and another one to remove the old thing.

This is pretty standard for rolling signing keys and api auth methods and all kinds of stuff like that.

Definitely, and it’s how I’d do it as well, but the standard was written for the use case of companies on the scale of Google.

Which still support webbrowsers that were released before 2007. (But somehow, they can’t support Firefox Mobile. mmhhmk. Totally not a plot to get rid of mobile ad blocking.)

Or if the old approach is no longer trusted, simply refuse old tokens. Any users with the old tokens will simply be forced to re-authenticate.

So, let's say you're currently using RS256 JWTs, and you want to migrate to ES256. Your JWTs are stored by clients in various places - some of them might be short-term, some long-term, so you don't want to invalidate old ones (RS256 isn't broken yet).

How do you tell RS256 and ES256 JWTs apart - so you can figure out how to validate them - unless the JWT actually encodes that information?

The trick is that JWT APIs need to force developers to choose which algorithms they want - having a `decode_jwt` function is not a good idea, `decode_es256_jwt` is much better. It'd validate that the alg in the header is correct, and return a specific error if it's not - if that error is returned, the developer can try `decode_rs256_jwt`.

This is how I've designed the API used in my OpenID Connect implementation. It works wonderfully.

Reply on news.ycombinator.com