5 ms·

They're not even good for API tokens. There are valid use cases for storing data in a signed client-side token, but if you're going to do that then don't choose

They're not even good for API tokens. There are valid use cases for storing data in a signed client-side token, but if you're going to do that then don't choose JWT as your serialization format - there have been too many alg:none or other issues. Just do hmac-sha256(data, secret) instead.

rsj_hn 5y ago
yeah, I'm not a fan of JSON or XML signatures, but for some reason developers love them. I've given up on that battle
- lbriner 5y ago
  Why would you not like a solid mechanism for verifying that a data packet hasn't been tampered with? In the case of JWTs which live in the browser, it would be essential that they are signed. dotnet auth tokens are also signed, they are stored in cookies, is that any different?
derefr 5y ago
Middleware like Nginx (at least the Nginx Plus version) know how to take apart JWTs and use the stuff inside. The same can't be said for your arbitrary custom serialization format. The real use of JWTs is when you want third parties to be able to sign their own API requests, that your API will accept using the very same machinery by which it accepts your first-party-client API requests. If you use JWT, you can just pass the third party a private JWT signing key to use, add the corresponding public key to your validation set for JWT decode on your backend, and everything "just works."
- genghisjahn 5y ago
  Or use rsa for the token signing. 3rd party keeps the private. They send you the public. You can verify all the tokens. They are the only ones that can create new ones.
  - derefr 5y ago
    Yes; that is, in fact, how JWT works. The point of JWT is that it's an ecosystem of stuff that all has built-in support for doing this. You don't have to arrange for this kind of signing "by hand"; on most services that have JWT "accept" support, there's a portal with a configuration field where you can just paste in a public key. Same as adding a line to ~/.ssh/authorized_keys, but for web requests. (Yes, all of this is just a bad imitation of TLS client certificates. But browsers have a horrible, intrusive, non-syncing UX for client certificates. If they did with client certs what they do with cookies/passwords, nobody would have bothered to invent JWTs.)
- IgorPartola 5y ago
  That seems like a really specific use case. Under what circumstances would you want to do this?
  - derefr 5y ago
    A better use-case is having a third-party upstream service that you want your own service's users to be able to talk to directly — i.e. without using your service as an intermediary gateway. If you configure your third-party SaaS with your own JWT public key, you will be able to have your users 1. Log in with your service, receiving a JWT token 2. Send that token back to your service, as the auth key for authenticating as themselves with your service. 3. Also send that same token to the third party service, to authenticate requests against your service's account. (One place where I just set this up the other day: allowing users of a crypto app to make authenticated requests to Infura via the MetaMask browser extension, where we're paying for the Infura credits to enable that. We send the user a JWT token; the client JS uses that token to build an Infura URL, and configures the MetaMask SDK with it. Infura accepts the requests as coming from "us" because it recognizes the JWT signing key we configured.)
  - hrktb 5y ago
    We hit this case with a customer service where each “domain” (transaction management, fidelity, auth, catalog data, etc.) was handled by a different internal org, with an orchestrating layer on top. Having the emitting entity sign their request in a standard format that can be checked by anything having with their public key helped a lot.
  - lbriner 5y ago
    Most web frameworks support JWT out of the box so just calling a web service written in these means it is preferable to use an existing format rather than rolling your own. Sure there are some gotchas but it isn't that hard to read up on that once, configure your JWT check and then leave it alone. Also, we pass additional claims in the JWT that avoids the need for the web service having to check certain permissions or auth status itself (like what resources the user has requested) and this is going to be a mess if you try and "just HMAC(SHA256())"
BelenusMordred 5y ago
> Just do hmac-sha256(data, secret) instead Or use SHA3(secret || data), it was specifically designed to not have the pitfalls of sha2 which made HMAC constructions necessary along with being less computationally expensive. There's also KMAC built from keccak which has some advantages over simply hashing the concatenated key and message. https://csrc.nist.gov/publications/detail/sp/800-185/final https://csrc.nist.gov/publications/detail/sp/800-185/final https://crypto.stackexchange.com/questions/17735/is-hmac-needed-for-a-sha-3-based-mac https://crypto.stackexchange.com/questions/17735/is-hmac-nee...
- josephg 5y ago
  A friendly reminder for the 99% of people here who, like me, don’t live and breathe this stuff: Don’t “just” use some crypto construction you read on HN. Don’t invent your own thing. Find a well respected crypto library (eg libsodium) and look up your use case in the API documentation. Eg, for authentication libsodium exposes these API methods: https://libsodium.gitbook.io/doc/secret-key_cryptography/secret-key_authentication https://libsodium.gitbook.io/doc/secret-key_cryptography/sec...
  - chupasaurus 5y ago
    That's why Cryptographic Right Answers [0] is a thing. [0] https://latacora.singles/2018/04/03/cryptographic-right-answers.html https://latacora.singles/2018/04/03/cryptographic-right-answ...
    - tialaramex 5y ago
      As that version of the post alludes to (in talking about D-H) the problem is that the people who most need these answers don't know how to ask their question in a suitable way. The NaCl/ Sodium APIs are oriented around applications. You want to do X, Sodium says you should call this API and the things you get back have the following properties. For example, what Sodium will actually do for the API your parent mentioned is HMAC-SHA512-256 ie it's using SHA512/256. But rather than give that as advice (and risk some developer either trying to re-implement SHA512/256 because their tool doesn't offer it, or worse, thinking SHA512 sounds strictly better so they'll do that) - Sodium just implements the thing you should do. But if I were going to write a snarky "Right Answers" type post about this subject what it would say is that JWT almost certainly isn't the solution to a problem you have, it might be a solution to a problem you wish you had, but you likely have actual problems, now, and you should work on those. Why do I say "wish" you had? Well as we see in a lot of these threads, immediately people talk about how it'll be a struggle to scale up the naive session approach when you have this big geographically distributed system. If your startup becomes Facebook or Google, you'll have to rewrite all this stuff. Why not instead use JWTs? Your startup isn't going to be Facebook or Google. When you prove me wrong you'll have piles of cash for engineers to fix the scaling problems you knew about and, much more importantly, all the other problems you'd never dreamed of. You are attempting premature optimisation.

rsj_hn 5y ago

yeah, I'm not a fan of JSON or XML signatures, but for some reason developers love them. I've given up on that battle

lbriner 5y ago
Why would you not like a solid mechanism for verifying that a data packet hasn't been tampered with? In the case of JWTs which live in the browser, it would be essential that they are signed. dotnet auth tokens are also signed, they are stored in cookies, is that any different?

derefr 5y ago

Middleware like Nginx (at least the Nginx Plus version) know how to take apart JWTs and use the stuff inside. The same can't be said for your arbitrary custom serialization format. The real use of JWTs is when you want third parties to be able to sign their own API requests, that your API will accept using the very same machinery by which it accepts your first-party-client API requests. If you use JWT, you can just pass the third party a private JWT signing key to use, add the corresponding public key to your validation set for JWT decode on your backend, and everything "just works."

genghisjahn 5y ago
Or use rsa for the token signing. 3rd party keeps the private. They send you the public. You can verify all the tokens. They are the only ones that can create new ones.
- derefr 5y ago
  Yes; that is, in fact, how JWT works. The point of JWT is that it's an ecosystem of stuff that all has built-in support for doing this. You don't have to arrange for this kind of signing "by hand"; on most services that have JWT "accept" support, there's a portal with a configuration field where you can just paste in a public key. Same as adding a line to ~/.ssh/authorized_keys, but for web requests. (Yes, all of this is just a bad imitation of TLS client certificates. But browsers have a horrible, intrusive, non-syncing UX for client certificates. If they did with client certs what they do with cookies/passwords, nobody would have bothered to invent JWTs.)
IgorPartola 5y ago
That seems like a really specific use case. Under what circumstances would you want to do this?
- derefr 5y ago
  A better use-case is having a third-party upstream service that you want your own service's users to be able to talk to directly — i.e. without using your service as an intermediary gateway. If you configure your third-party SaaS with your own JWT public key, you will be able to have your users 1. Log in with your service, receiving a JWT token 2. Send that token back to your service, as the auth key for authenticating as themselves with your service. 3. Also send that same token to the third party service, to authenticate requests against your service's account. (One place where I just set this up the other day: allowing users of a crypto app to make authenticated requests to Infura via the MetaMask browser extension, where we're paying for the Infura credits to enable that. We send the user a JWT token; the client JS uses that token to build an Infura URL, and configures the MetaMask SDK with it. Infura accepts the requests as coming from "us" because it recognizes the JWT signing key we configured.)
- hrktb 5y ago
  We hit this case with a customer service where each “domain” (transaction management, fidelity, auth, catalog data, etc.) was handled by a different internal org, with an orchestrating layer on top. Having the emitting entity sign their request in a standard format that can be checked by anything having with their public key helped a lot.
- lbriner 5y ago
  Most web frameworks support JWT out of the box so just calling a web service written in these means it is preferable to use an existing format rather than rolling your own. Sure there are some gotchas but it isn't that hard to read up on that once, configure your JWT check and then leave it alone. Also, we pass additional claims in the JWT that avoids the need for the web service having to check certain permissions or auth status itself (like what resources the user has requested) and this is going to be a mess if you try and "just HMAC(SHA256())"

BelenusMordred 5y ago

> Just do hmac-sha256(data, secret) instead Or use SHA3(secret || data), it was specifically designed to not have the pitfalls of sha2 which made HMAC constructions necessary along with being less computationally expensive. There's also KMAC built from keccak which has some advantages over simply hashing the concatenated key and message. https://csrc.nist.gov/publications/detail/sp/800-185/final https://csrc.nist.gov/publications/detail/sp/800-185/final https://crypto.stackexchange.com/questions/17735/is-hmac-needed-for-a-sha-3-based-mac https://crypto.stackexchange.com/questions/17735/is-hmac-nee...

josephg 5y ago
A friendly reminder for the 99% of people here who, like me, don’t live and breathe this stuff: Don’t “just” use some crypto construction you read on HN. Don’t invent your own thing. Find a well respected crypto library (eg libsodium) and look up your use case in the API documentation. Eg, for authentication libsodium exposes these API methods: https://libsodium.gitbook.io/doc/secret-key_cryptography/secret-key_authentication https://libsodium.gitbook.io/doc/secret-key_cryptography/sec...
- chupasaurus 5y ago
  That's why Cryptographic Right Answers [0] is a thing. [0] https://latacora.singles/2018/04/03/cryptographic-right-answers.html https://latacora.singles/2018/04/03/cryptographic-right-answ...
  - tialaramex 5y ago
    As that version of the post alludes to (in talking about D-H) the problem is that the people who most need these answers don't know how to ask their question in a suitable way. The NaCl/ Sodium APIs are oriented around applications. You want to do X, Sodium says you should call this API and the things you get back have the following properties. For example, what Sodium will actually do for the API your parent mentioned is HMAC-SHA512-256 ie it's using SHA512/256. But rather than give that as advice (and risk some developer either trying to re-implement SHA512/256 because their tool doesn't offer it, or worse, thinking SHA512 sounds strictly better so they'll do that) - Sodium just implements the thing you should do. But if I were going to write a snarky "Right Answers" type post about this subject what it would say is that JWT almost certainly isn't the solution to a problem you have, it might be a solution to a problem you wish you had, but you likely have actual problems, now, and you should work on those. Why do I say "wish" you had? Well as we see in a lot of these threads, immediately people talk about how it'll be a struggle to scale up the naive session approach when you have this big geographically distributed system. If your startup becomes Facebook or Google, you'll have to rewrite all this stuff. Why not instead use JWTs? Your startup isn't going to be Facebook or Google. When you prove me wrong you'll have piles of cash for engineers to fix the scaling problems you knew about and, much more importantly, all the other problems you'd never dreamed of. You are attempting premature optimisation.