4 ms·

The first comment from 11 months ago is wrong. >JWTs are useful, but there are a few things that are not immediately obvious. >1) They are signed not encrypted

The first comment from 11 months ago is wrong. >JWTs are useful, but there are a few things that are not immediately obvious. >1) They are signed not encrypted. This is not true. JWT's can be encrypted, signed, or both (nested). One might first look to see if this misconception is the fault of a poorly written spec, but it's literally in the second sentence of the abstract and plain as day in the introduction. People are simply not reading it. https://tools.ietf.org/html/rfc7519 https://tools.ietf.org/html/rfc7519 It drives me mad when people refer to JWT's as basically JWS's, ignoring the rest of the JWT standard and JOSE. The fact that these misconceptions continue to be up voted shows the broad misunderstanding of the standard.

falcolas 7y ago
Or, they highlight that the spec is overly complicated. And a complicated spec is very challenging to implement both correctly and safely. EDIT: Case in point, all the disagreements and conflicting best practices throughout the threads on this topic.
- AmericanChopper 7y ago
  I think complex specs are fine. Complex and under defined spec are a nightmare. I had to work on a WebAuthn project recently. That spec is rather complex, but makes perfect sense after you take the time to understand it. More recently, I had to answer a very simple question about X.509. After spending half a day reading the RFC (and about half a dozen other dependant specifications), I gave up and concluded that the question did not have an answer, the best I could come up with was some general graph theory principles relating to DIT.
  - speedplane 7y ago
    > I think complex specs are fine. Complex and under defined spec are a nightmare. Perhaps, but in practice there generally seems to be a correlation between complexity of a specification and holes in the specification (e.g., html, pdf, etc.).
    - AmericanChopper 7y ago
      Complexity, whether necessary or not, makes it harder to maintain a spec. But I’d argue that it’s other issues, whether they’re symptoms of complexity or not, that make it hard to implement. Some things have to be complex, but they don’t have to be full of problems.
davewritescode 7y ago
Thank you for this comment, I feel very much the same way. The JWT spec isn’t wonderful and it is complex however, having spent the early part of my career working with SAML, SOAP and xmldsig in highly trusted environments it’s actually a breath of fresh air. Those specs were littered with security flaws. That said, the class of attacks that relied on the attacker modifying the header of the JWT could have been totally avoided by including the header values in the signature calculation.
Bombthecat 7y ago
Or you work with an opaque token. Then no one knows what's inside...

falcolas 7y ago

Or, they highlight that the spec is overly complicated. And a complicated spec is very challenging to implement both correctly and safely. EDIT: Case in point, all the disagreements and conflicting best practices throughout the threads on this topic.

AmericanChopper 7y ago
I think complex specs are fine. Complex and under defined spec are a nightmare. I had to work on a WebAuthn project recently. That spec is rather complex, but makes perfect sense after you take the time to understand it. More recently, I had to answer a very simple question about X.509. After spending half a day reading the RFC (and about half a dozen other dependant specifications), I gave up and concluded that the question did not have an answer, the best I could come up with was some general graph theory principles relating to DIT.
- speedplane 7y ago
  > I think complex specs are fine. Complex and under defined spec are a nightmare. Perhaps, but in practice there generally seems to be a correlation between complexity of a specification and holes in the specification (e.g., html, pdf, etc.).
  - AmericanChopper 7y ago
    Complexity, whether necessary or not, makes it harder to maintain a spec. But I’d argue that it’s other issues, whether they’re symptoms of complexity or not, that make it hard to implement. Some things have to be complex, but they don’t have to be full of problems.

davewritescode 7y ago

Thank you for this comment, I feel very much the same way. The JWT spec isn’t wonderful and it is complex however, having spent the early part of my career working with SAML, SOAP and xmldsig in highly trusted environments it’s actually a breath of fresh air. Those specs were littered with security flaws. That said, the class of attacks that relied on the attacker modifying the header of the JWT could have been totally avoided by including the header values in the signature calculation.

Bombthecat 7y ago

Or you work with an opaque token. Then no one knows what's inside...