39 ms·

I just documented how it should be done, in the article at the top of the page. The answer is "don't use JWT." Use specific tools for the thing you are actually

I just documented how it should be done, in the article at the top of the page. The answer is "don't use JWT." Use specific tools for the thing you are actually trying to do, that have API's that are harder to mess up.

Minikloon 9y ago
By that logic the answer is also "don't use SQL".
- kevinburke 9y ago
  More like "Don't use SQL, if a thing adjacent to SQL exists that is better suited to a particular use case, doesn't have a history of poor implementations, and is harder for implementers and end users to screw up." In this case: - crypto_auth, or HMAC-SHA256 by itself, for authentication - crypto_secretbox for symmetric encryption - crypto_box or TLS for public key encryption
  - wolco 9y ago
    But what happens is that sql version becomes sqlite and it doesn't provided enough power or flexibility.
  - deathanatos 9y ago
    Good JWT libraries essentially have a "box" and "unbox" function; the work required by the client needed to go behind the library's back here is on the same level as that needed to behind crypto_box's. Further, crypto_box works on a lower level than JWT encode/decode functions typically do, and would leave many concerns that JWTs handle in the user's hands for them to handle, alone. Having the user write their own code to handle those concerns is a terrible idea.
    - mmalone 9y ago
      I'm with you on this. I've never thought of JWTs as a session storage mechanism; rather, I've always thought of them as a simpler (JSON-based) alternative to technologies like X.509 attribute certificates and SAML assertions. If you're creating a ticket / verifiable claim, there are a bunch of security considerations that JWT at least lays the groundwork for, and that NaCl secretbox doesn't appear to offer. Curious what OP thinks about putting things like payload canonicalization, subject/issuer/audience specification, and expiration entirely in the user's hands. I suppose its up to implementors to do appropriate validation, but at least JWT simplifies the conversation a bit.
rattray 9y ago
> Use specific tools for the thing you are actually trying to do, that have API's that are harder to mess up. That sounds like it would require a greater amount of knowledge to do correctly than "careful JWT".
- kevinburke 9y ago
  "Careful JWT" implies you know what you should be careful about. If you know that much, you should just use the better things. It also ignores the role JWT plays in promoting bad security practices

Minikloon 9y ago

By that logic the answer is also "don't use SQL".

kevinburke 9y ago
More like "Don't use SQL, if a thing adjacent to SQL exists that is better suited to a particular use case, doesn't have a history of poor implementations, and is harder for implementers and end users to screw up." In this case: - crypto_auth, or HMAC-SHA256 by itself, for authentication - crypto_secretbox for symmetric encryption - crypto_box or TLS for public key encryption
- wolco 9y ago
  But what happens is that sql version becomes sqlite and it doesn't provided enough power or flexibility.
- deathanatos 9y ago
  Good JWT libraries essentially have a "box" and "unbox" function; the work required by the client needed to go behind the library's back here is on the same level as that needed to behind crypto_box's. Further, crypto_box works on a lower level than JWT encode/decode functions typically do, and would leave many concerns that JWTs handle in the user's hands for them to handle, alone. Having the user write their own code to handle those concerns is a terrible idea.
  - mmalone 9y ago
    I'm with you on this. I've never thought of JWTs as a session storage mechanism; rather, I've always thought of them as a simpler (JSON-based) alternative to technologies like X.509 attribute certificates and SAML assertions. If you're creating a ticket / verifiable claim, there are a bunch of security considerations that JWT at least lays the groundwork for, and that NaCl secretbox doesn't appear to offer. Curious what OP thinks about putting things like payload canonicalization, subject/issuer/audience specification, and expiration entirely in the user's hands. I suppose its up to implementors to do appropriate validation, but at least JWT simplifies the conversation a bit.

rattray 9y ago

> Use specific tools for the thing you are actually trying to do, that have API's that are harder to mess up. That sounds like it would require a greater amount of knowledge to do correctly than "careful JWT".

kevinburke 9y ago
"Careful JWT" implies you know what you should be careful about. If you know that much, you should just use the better things. It also ignores the role JWT plays in promoting bad security practices