[akfish]

I don't see any valid arguments in the post. The issues raised are either mis-implementation or misuse of JWT. All I am getting is "JWT can be misused in such such way that makes your application vulnerable. And neither its standards nor libraries prevent that, so it sucks".

But when is the last time we see any technology successfully prevented people from being silly?

[sgift]

> But when is the last time we see any technology successfully prevented people from being silly?

You can never stop someone sufficiently motivated to shoot himself in the foot from doing it. But you can make it harder for those who would do it be accident by providing more safety features - in case of security this is usually seen as a good idea (safe defaults etc.)

[revelation]

But this is the biggest thing with any security-sensitive code or practice!

Do not give people options, do not allow algorithmic flexibility, do not have fallbacks, do not have backward compatibility, do not allow "testing" or "insecure" options, do not have complex state machine behavior.

All of these things are exactly what JWT or other "design by commission" standards like SSL suffer from and they have predictably lead to ongoing, at times unfixable security problems.

[ponytech]

I agree. I've read the whole article and still wonder why I should stop using JWT.

[slau]

You shouldn't. Simply check that the hash algorithm specified by the client is the one you used when issuing the token. In a side project, I simply hard code the algorithm [1].

[1]: https://github.com/teotwaki/grace-calendar/blob/develop/app/...

Edit: DYAC.

[nallerooth]

+1. I read the article and ended up with a TLDR where I expected some explanation and facts.

It's a good thing that cookies have never been used in a bad manner. /sarcasm

[RegEx]

https://github.com/rails/rails/issues/5228