да она повсюду

аутентификация каждого критического действия, наверно, безопасней

Каким образом? Через ввод логина пароля?

@@no101vmv Ну много вариантов. например одноразовый код. Это конечно, немного разное - JWT и безопасность, но все же. Просто в токене не нужно передавать чувствительные данные, а сам токен можно выдавать под каждое (только одно) действие, и проверять подпись, разумеется. Приемущиство JWT просто в том, что не нужно на каждый запрос ходить в сервис аутентификации для его валидации, а сам сервис не должен эти токены хранить в базе данных. А, чтобы токеном не мог воспользоваться кто-то другой, например, можно цифровой отпечаток в токен сунуть (и подделать его будет нельзя, из-за подписи) - хотя бы тот же IP или еще, что нибудь придумать. Главное не делать этого с refresh токеном, а то подобные отпечатки в нем приведут к постоянной необходимости в аутентификации. В целом TLS, RS512, отпечаток, и одноразовасть токена выглядит безопасно. Однако если делать токены одноразовыми (например, через поле jti), то сервису, его выдавшему все же придется хранить эти токены, как использованные, а сервису, который использует эти токены для авторизации действия придется ходить в сервис аутентификации для валидации и инвалидации токенов. Так же если все таки нужно шифровать данные в токене, то JWS, вроде как это поддерживает (спецификация)

​@@no101vmvодноразовые пароли?

Эт кодить надо, а не языком честь, ты чего))

Да, ключ естественно другой и время жизни, payload по вкусу

по идее сервис должен знать секрет. Когда присылаем ему payload + signature, сервис берем payload и с помощью секрета подписывает его и получает свою signature. Если переданная и рассчитанная signature совпадают, то значит токен валиден

@@ilyakushlianski6519 Секрет нужен для шифрования токена. А для валидации публичный ключ. Вот им уже можно делиться с другими приложениями.

Если имеется ввиду клиент, то никак.

А смысл, если всё передаётся по https

Теряется смысл использования JWT, если при каждом запросе надо лезть в БД.

@@MrLotrusВсмысле? Так в токене лежит к примеру userId, мы отправляем запрос на получение к примеру постов пользователя, в запросе отправляем токен, на сервере в данных с jwt получаем userId и по этому айди ищем посты у которых userId автора совпадает с userId который пришёл в запросе. О каком смысле jwt с бд ты говоришь?

@@sochilling у тя уже есть подпись токена, которая на стороне сервера делается, просто клади в payload доп инфу, типа ролей

Что

@@user-ik5jz4yv5j Видос.

Нужно делать чёрные или белые списки рефреш токенов в базе и во время каждого рефреша проверять по наличию в базе. Так же в профиле/аккаунте пользователя нужно сделать кнопку "Выйти на других устройствах", которая инвалидирует остальные токены этого пользователя из белого списка.

Возможны, ситуации как я понимаю, когда ip может меняться слишком часто. Например, в случае мобильной связи

Злоумышленник все знает о ip и девайсе. Шифруется только secret, Payload просто использует HS256 или что-то еще.

Вероятно, что в таком случае токен будет инвалидироваться слишком часто в мобильных устройствах

В видео не рассмотрен вопрос как вход/доступ с нескольких устройств (рабочий комп/домашний/ноут) или смартфона, те ip постоянно меняется, те надо делать коллекцию RT пользователя, где-то хранить, проверять "протухшие" и тп и тд, так что возни много

Сессии