4 ms·

For my current use-case, one of the appealing things about JWT is there are libraries for just about every language, which makes it easy for 3rd party developer

For my current use-case, one of the appealing things about JWT is there are libraries for just about every language, which makes it easy for 3rd party developers to integrate with my service. Are there any better alternatives to JWT that have implementations in many languages? If not, elsewhere in this thread tptacek and others have suggested essentially `base64_encode(crypto_auth(json_encode(object)))` would be sufficient... is there any reason not to just slap a name on that "standard" and publish a bunch of libraries?

ash 10y ago
I was confused about libsodium/NaCl APIs, specifically crypto_sign vs crypto_auth. The difference: 1. `crypto_auth` is for secret-key signatures (auth): https://download.libsodium.org/doc/secret-key_cryptography/secret-key_authentication.html https://download.libsodium.org/doc/secret-key_cryptography/s... 2. `crypto_sign` is for public-key signatures: https://download.libsodium.org/doc/public-key_cryptography/public-key_signatures.html https://download.libsodium.org/doc/public-key_cryptography/p... And tptacek is arguing secret (symmetric) key is preferable: https://news.ycombinator.com/item?id=13866983 https://news.ycombinator.com/item?id=13866983
- unscaled 10y ago
  Symmetric signature is simpler, leaner (in message size overhead), faster and more secure (by virtue of it being simpler). But there are still cases where you would choose asymmetric signatures over symmetric signature, due to the very essence of it being asymmetric. The rule of thumb is that when you want to produce a cryptographic token that will be consumed by parties which you don't trust, you should use an asymmetric signature. Realistically speaking, the untrusted party could (and very often should) be almost any other service inside your own company. If you let symmetric keys spread around, you should treat them as good as if they've been leaked. There is an alternative that if you're able to (and willing to) manage shared secrets through a safe out-of-band channel (e.g. deriving from client secrets).
deathanatos 10y ago
> is there any reason not to just slap a name on that "standard" and publish a bunch of libraries? It was called JWT. jwt.decode(token, 'secret', algorithms=['HS256']) That's the Python for JWT; encode is similar. You can try something like what you suggest, but the devil is in "object": want your token to expire after a finite amount of time? You'll need to encode that yourself. Token need to be valid only for certain cases? You'll need to encode that yourself. Essentially, you end up reinventing the part of JWT that is relevant to your use-case, and hopefully, arrive at a decent API. At least in Python, python-jose's APIs will check not only the signature, but these additional claims (expiration of the token, that the token is applicable to the use we're verifying it for). (I still think we should be moving towards a common API (and JWT is good enough) and building libraries around that standard. They're going to fall short in some ways at first, and I wish people would help improve them. The suggestion of using base64/libsodium feel dangerously close to "rolling your own", because its too low-level for the purpose at hand.)

ash 10y ago

I was confused about libsodium/NaCl APIs, specifically crypto_sign vs crypto_auth. The difference: 1. `crypto_auth` is for secret-key signatures (auth): https://download.libsodium.org/doc/secret-key_cryptography/secret-key_authentication.html https://download.libsodium.org/doc/secret-key_cryptography/s... 2. `crypto_sign` is for public-key signatures: https://download.libsodium.org/doc/public-key_cryptography/public-key_signatures.html https://download.libsodium.org/doc/public-key_cryptography/p... And tptacek is arguing secret (symmetric) key is preferable: https://news.ycombinator.com/item?id=13866983 https://news.ycombinator.com/item?id=13866983

unscaled 10y ago
Symmetric signature is simpler, leaner (in message size overhead), faster and more secure (by virtue of it being simpler). But there are still cases where you would choose asymmetric signatures over symmetric signature, due to the very essence of it being asymmetric. The rule of thumb is that when you want to produce a cryptographic token that will be consumed by parties which you don't trust, you should use an asymmetric signature. Realistically speaking, the untrusted party could (and very often should) be almost any other service inside your own company. If you let symmetric keys spread around, you should treat them as good as if they've been leaked. There is an alternative that if you're able to (and willing to) manage shared secrets through a safe out-of-band channel (e.g. deriving from client secrets).

deathanatos 10y ago

> is there any reason not to just slap a name on that "standard" and publish a bunch of libraries? It was called JWT. jwt.decode(token, 'secret', algorithms=['HS256']) That's the Python for JWT; encode is similar. You can try something like what you suggest, but the devil is in "object": want your token to expire after a finite amount of time? You'll need to encode that yourself. Token need to be valid only for certain cases? You'll need to encode that yourself. Essentially, you end up reinventing the part of JWT that is relevant to your use-case, and hopefully, arrive at a decent API. At least in Python, python-jose's APIs will check not only the signature, but these additional claims (expiration of the token, that the token is applicable to the use we're verifying it for). (I still think we should be moving towards a common API (and JWT is good enough) and building libraries around that standard. They're going to fall short in some ways at first, and I wish people would help improve them. The suggestion of using base64/libsodium feel dangerously close to "rolling your own", because its too low-level for the purpose at hand.)