Learn-json-web-tokens: Почему «одноразовое использование» могло решить MITM?

@ NE-SmallTown хороший вопрос.
Использование одноразовых токенов - хорошая практика для безопасности приложений.
Если вы хотите использовать этот шаблон, вы можете настроить ловушку onPreResponse которая автоматически обновляет JWT для каждого ответа.

вопрос, на который вы должны ответить: как вы планируете гарантировать, что токен _не_ повторно используется?
вам нужно будет сохранить идентификатор в какой-то базе данных (_ мы обычно используем для этого redis в наших приложениях_) и проверить, был ли уже использован токен.

@nelsonic Спасибо за ответ. Я немного запутался.

Есть вопрос.

Как вы говорите, процесс такой:

пользователь получает доступ к домашней странице и отправляет токен в заголовке (при условии, что они вошли в систему)

                                       |
                                       |
                                       ↓

сервер получает токен, а затем получает userId путем декодирования токена, а затем переходит к базе данных (при условии, что я использую базу данных, а не redis ), чтобы взять соответствующий токен userId , а затем проверьте, равны ли они, используя оператор == это так, то уничтожьте токен и сгенерируйте новый токен, отправьте его в базу данных и ответьте на него и данные клиенту.

Возникает вопрос, мы просто используем оператор == для проверки, но мы знаем, что сам токен имеет механизм проверки, мы его не используем ? Например:

JWT.require(Algorithm.RSA256((RSAKey) publicKey))
                .withIssuer("auth")
                .withSubject("ne-smalltown")
                .withAudience(userId)
                .withArrayClaim("jwt-role", userRole)
                .build()

Если я ошибаюсь, не могли бы вы рассказать мне, как и где использовать механизм проверки самого токена, как указано выше?

IMO, единственное место, где я могу использовать механизм проверки самого токена, - это когда я получаю параметр exp старого токена и помещаю его в новый токен, чтобы я мог проверить, не устарел ли токен, чтобы пользователь мог повторно войти в систему.

                                        |
                                        |
                                        ↓

Клиент получает новый токен и помещает его в localstorage чтобы заменить старый токен, и в следующем запросе он будет его использовать.

@nelsonic Привет?

@ NE-SmallTown, приношу свои извинения за то, что не ответил немедленно.
В спецификации JWT нет утверждения / механизма для одноразовой недействительности.
см. http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#RegisteredClaimName

@jbspeakr имеет сообщение о том, как одноразовые JWT,
см .: https://www.jbspeakr.cc/howto-single-use-jwt/

@nelsonic Спасибо, что поделились этим сообщением.

В сообщении говорится:

Теоретически это также работает с вариантами использования, помимо токенов сброса пароля, например, активация электронной почты, подтверждение учетной записи.

Я согласен с тем, что эти случаи подходят для single-use-jwt, но в моем случае jwt включает информацию о роли постоянна , ему не нравится сброс пароля, активация электронной почты, подтверждение учетной записи и т. Д.

Итак, возвращаясь к вопросу, в моем случае теперь я думаю, что нет необходимости проверять токен, просто используйте оператор == с токеном базы данных.