@RPiontik если что, мне правда интересен ответ на этот вопрос — я хочу эти реализации потыкать палочкой. но меня только под ноду интересуют.

Я не понял, ответ про сессию или jwt?

Да он в исходном сообщении немного криво написал, он имел ввиду сессии, очевидно. (Я не согласен, но не готов сейчас об этом устраивать дискуссию).

В исходном он написал что jwt это зло

Вот там и криво написал. Он имел ввиду сессии. (Опять же: я не согласен).

Не.. я могу пояснить, почему джуны так делают. У меня теория есть. Они тянут древние примеры. Когда еще был серверрендеринг. О каком jwt там вообще речь?

А из этой древности родились первые spa. И там юзали то, что есть... уже...

И вот гора кода и примеров...

Используй то что проще тебе. Относись к этому как к деталям которые всегда можно заменить.

Да я тоже серьезно - смрашивайте. Что знаю скажу. Что не знаю, врать не буду.

Я выше спросил )

Не. Если мне не изменяет память, жвт по спеке при проверке ходит по урлам, указанным в токене. И скачивает оттуда штуки. В процессе валидации, то есть до неё.

Мне интересно, какие либы поддерживают этот кусок спецификации, а то большая часть либ жвт неполноценны по очевидным причинам.

Совет правильный, но его не используют)

Сессию. JWT замещает общепринятое понятие сессии в web. Лучше скащать не могу.

Js тоже много чего по спекам имеет, но v8 до сих пор не поддерживает

М? Ты про многострадальный TCO?
Или я чего-то не знаю?

Ну типа, да, надо писать приложухи, в которых ты легко что-то можешь заменить, но делает это +- никто

Если за спиной не стоит синьёр, который пиздит по рукам каждую минуту

Нет в jwt урлов. Может ты что-то иное имеешь ввиду? Есть, как необязательный, источник генерации. Но это uri, а не url. Типа идентиыикатор ресурса выдавший токен. И сервис, теоретически, может его переспросить о достоверности токена. Но это уже от системы зависит.

Мне хватает того, что есть в ноде для моего пета по IoT. На работе более сложные решения.

Не, там именно написано чёрным по белому:

  This MAY be followed by additional
   certificates, with each subsequent certificate being the one used to
   certify the previous one.  The protocol used to acquire the resource
   MUST provide integrity protection; an HTTP GET request to retrieve
   the certificate MUST use TLS [RFC2818] [RFC5246]; and the identity of
   the server MUST be validated, as per Section 6 of RFC 6125 [RFC6125].
   Also, see Section 8 on TLS requirements.  Use of this Header
   Parameter is OPTIONAL.

https://tools.ietf.org/html/rfc7515#section-4.1.5

Ща скаду, что использую...