0
$\begingroup$

One of the primary advantages of JWTs is that they serve as capability tokens, allowing for a portable verification of capabilities/ privileges. However, JWTs are often criticized for a number of weaknesses.

What is the disadvantage of simply applying an HMAC to a JSON object yourself and avoiding the rest of the baggage of the JWT spec?

$\endgroup$
  • $\begingroup$ Latacora published a great blog post on this recently: latacora.micro.blog/2019/07/24/how-not-to.html $\endgroup$ – Prime Aug 28 '19 at 15:10
  • $\begingroup$ Although it makes an interesting read (even though it certainly has its issues) your post is not considered an answer. I'll change into a comment for you, but please note that there is a good reason for the rep. requirements for commenting. If you want to post an answer, you should at the minimum list the issues in short form and then link. $\endgroup$ – Maarten Bodewes Aug 28 '19 at 15:57
  • $\begingroup$ The portable verification would only happen if the HMAC secret is shared among N services. A better approach would be for one service to sign with its private key and then other services verify the token with the issuer service public key. In this way, if one service is attacked with success, other services would still be safe to operate and the attacker's service/node can be shutdown and replaced drop-in with a new/fresh public & private key pair. $\endgroup$ – Marco Aurélio da Silva Aug 30 '19 at 14:12
1
$\begingroup$

Disadvantage: You don't get the thrill of playing Russian roulette with a dumpster fire of an implementation ecosystem and underspecified protocol!

Disadvantage: You might accidentally reinvent JWT and repeat its errors anew if you're not careful. (On the other hand, advantage: you might not.)

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.