28 ms·

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

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.

theprotocol 9y ago
You could even hit 2 birds with 1 stone by going with headerless JWTs (just strip the first segment).
- Freak_NL 9y ago
  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).
  - theprotocol 9y ago
    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.
    - vertex-four 9y ago
      Symmetric signing is not, by far, the only use case for JWTs. Asymmetric signing, and encryption, are also well-specified and supported.
      - theprotocol 9y ago
        Good point! It slipped my mind.
- lclarkmichalek 9y ago
  There's some value in the header. Google use it to store the keyid, which is pretty useful.
- davis_m 9y ago
  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.
kuschku 9y ago
The question is: what if you change the algorithm on the server, and a user still has an old token.
- zxcmx 9y ago
  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.
  - kuschku 9y ago
    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.)
  - Freak_NL 9y ago
    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.
  - vertex-four 9y ago
    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.

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.

theprotocol 9y ago

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

Freak_NL 9y ago
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).
- theprotocol 9y ago
  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.
  - vertex-four 9y ago
    Symmetric signing is not, by far, the only use case for JWTs. Asymmetric signing, and encryption, are also well-specified and supported.
    - theprotocol 9y ago
      Good point! It slipped my mind.
lclarkmichalek 9y ago
There's some value in the header. Google use it to store the keyid, which is pretty useful.
davis_m 9y ago
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.

kuschku 9y ago

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

zxcmx 9y ago
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.
- kuschku 9y ago
  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.)
- Freak_NL 9y ago
  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.
- vertex-four 9y ago
  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.