Весёлые дыры:
2015: кто-то прочитал спеку и внезапно заметил что токены, в которых стоит "alg": "none" валидны всегда, а ограничений в либах никто не предусмотрел, и народ просто проверял JWT на валидность.
https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
2017 (начало года): Атака на извлечение приватного ключа с сервера, по протоколу.
https://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html
2017 (конец года): кто-то прочитал спеку ещё раз и заметил, что «самоподписанные» токены, которые включают в себя свой ключ, валидны всегда. А народ всё ещё тупо проверяет JWT на валидность. Это затронуло, например, node-jose. Исправили со сломом совместимости.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0114

C JWT много чего не так, и небезопасное хранение его — только одна из проблем.

JWT это заоверенжинеренное говно, в котором до сих пор находят эпичные баги фактически на уровне спецификации.

Народ, кто юзает JWT — вы вообще в курсе, что он по спеке при проверке токена (то есть до подверждения его валидности) ходит по урлам, указанным в этом токене?

С вашего сервера.

От этого пока всё вокруг не сгорело скорее всего потому, что в либах JWТ эту часть пока не реализовали (JWT ­— заоверенжинерен, с реализациями плохо всё).

Но это не значит что эта чудесная фича вам однажды не прилетит с обновлениями зависимостей.

А в ссылке выше (на joepie91) объясняется, почему это ещё и ненужное говно.

Извините, я опять стриггерилсяя на слово jwt.

Основная часть JWT — это вот эта пачка спек:
https://tools.ietf.org/html/rfc7519
https://tools.ietf.org/html/rfc7515
https://tools.ietf.org/html/rfc7516

https://tools.ietf.org/html/rfc7515#section-4.1.5 — вот тут про хождение по урлам в процессе валидации, например. Там оно в нескольких местах, емнип.

Простыня^^

Ссылки на joepie91 рекомендую посмотреть. Ну или флоучарт хотя бы.

я читал joepie91

но я так же читал и owasp

но...я почитаю и поизучаю этот вопрос) еще более тщательно)

Гитхаб юзернейм дай :-)