Рекомендации по аннулированию JWT при изменении паролей и выходе из узла.Яш? [закрытый]
Я хотел бы знать лучшие практики для аннулирования JWT без нажатия db при изменении пароля/выхода из системы.
У меня есть идея ниже, чтобы обрабатывать выше 2 случаев, нажав на базу данных пользователя.
1.В случае изменения пароля я проверяю пароль(хэшированный), хранящийся в БД пользователя.
2.В случае выхода из системы я сохраняю время последнего выхода в пользовательской БД, поэтому, сравнивая время создания токена и время выхода, я могу сделать это недействительным случай.
но эти 2 случая происходят за счет удара пользователя db каждый раз, когда пользователь попадает в api. Любая лучшая практика приветствуется.
обновление: Я не думаю, что мы можем аннулировать JWT без попадания в db. И я нашел решение. Я отправил свой ответ, если у вас есть какие-либо проблемы, добро пожаловать.
5 ответов
когда токен обновления не используется:
1.При смене пароля: когда пользователь меняет свой пароль, обратите внимание на время изменения пароля в пользовательской БД, поэтому, когда время изменения пароля больше времени создания токена, Токен недействителен. Следовательно, оставшаяся сессия скоро выйдет из системы.
2.Когда пользователь выходит из системы: когда пользователь выходит из системы, сохраните токен в отдельной БД (скажем: InvalidTokenDB и удалите токен из БД по истечении срока действия токена). Следовательно, пользователь выходит из соответствующего устройства, его сеансы на другом устройстве остаются нетронутыми.
следовательно, при аннулировании JWT я выполняю следующие шаги:
- проверьте, является ли токен допустимым или нет.
- если он действителен, проверьте его наличие в invalidTokenDB (база данных, в которой маркеры выхода хранятся до истечения срока их действия).
- если его нет, то проверьте время создания и изменения токена пароль пользователя БД.
- если изменено время пароля
отношение к вышеуказанному методу:
- для каждого запроса API, мне нужно выполнить все вышеуказанные действия, которые могут повлиять на производительность.
когда используется токен обновления: с истечением срока действия маркера доступа как 1 день, обновить маркер как срок действия
1. При смене пароль: когда пользователь меняет свой пароль, измените токен обновления пользователя. Следовательно, оставшаяся сессия скоро выйдет из системы.
2. Когда пользователь выходит из системы: когда пользователь выходит из системы, сохраните токен в отдельной БД (скажем: InvalidTokenDB и удалите токен из БД по истечении срока действия токена). Следовательно, пользователь выходит из соответствующего устройства, его сеансы на другом устройстве остаются нетронутыми.
следовательно, при признании недействительным JWT, я следую ниже шаги:
- проверьте, является ли токен допустимым или нет
- если допустимо, проверьте, присутствует ли токен в InvalidTokenDB.
- если нет, проверьте маркер обновления с помощью маркера обновления в userDB.
- Если равно, то его действительный токен
отношение к вышеуказанному методу:
- для каждого запроса api мне нужно выполнить все вышеуказанные шаги, которые могут повлиять спектакль.
- как сделать недействительным токен обновления, так как токен обновления не имеет действительности, если его использует хакер, все равно аутентификация действительна, запрос всегда будет успешным.
Примечание: хотя Hanz предложил способ защитить токен обновления в использование маркера Refesh в аутентификации на основе маркеров защищено?, я не мог понять, что он говорит. Любая помощь приветствуется.
Итак, если у кого-нибудь есть хороший предложение, ваши комментарии приветствуются.
обновление: Я добавляю ответ, Если вашему приложению не нужен токен обновления с истечением срока службы. Этот ответ был дан Sudhanshu (https://stackoverflow.com/users/4062630/sudhanshu-gaur). Спасибо Sudhanshu. Поэтому я считаю, что это лучший способ сделать это,
когда не требуется токен обновления и нет истечения срока действия токенов доступа:
при входе пользователя в систему создайте логин токен в его пользовательской базе данных без срока действия.
следовательно, при аннулировании JWT выполните следующие действия,
- получить информацию о пользователе и проверить, находится ли маркер в его базе данных пользователей. Если позволите.
- когда пользователь выходит из системы, удалите только этот маркер из его базы данных пользователей.
- когда пользователь меняет свой пароль, удалите все маркеры из его базы данных пользователей и попросите его войти снова.
таким образом, с этим подходом вы не нужно хранить ни токены выхода из системы в базе данных до истечения срока их действия, ни хранить время создания токенов при смене пароля, что было необходимо в приведенных выше случаях. Однако я считаю, что этот подход только valids, если ваше приложение имеет требования без токена обновления и без истечения срока действия токенов.
Если кто-то имеет отношение к этому подходу, пожалуйста, дайте мне знать. Ваши комментарии приветствуются :)
Я не знаю, как произвольно аннулировать токен без привлечения базы данных так или иначе.
будьте осторожны с подходом 2, Если ваша служба может быть доступна на нескольких устройствах. Рассмотрим следующий сценарий...
- пользователь входит в систему с iPad, маркер 1 выдан и хранится.
- пользователь входит на сайт. Выпущен токен 2. Журналы пользователя.
- пользователь пытается использовать iPad, токен 1 был выпущен до выхода пользователя из системы с веб-сайта токен 1 теперь считается недействительным.
вы можете посмотреть на идею обновления хотя они требуют хранения базы данных тоже.
см. Также здесь для хорошего обсуждения SO относительно аналогичной проблемы, в частности решения IanB, которое сохранит некоторые вызовы db.
предлагаемое решение Лично я бы подошел к этому так...аутентификация пользователя, выданная с доступом токен с коротким сроком действия (скажем, 15 минут) и токен обновления действителен либо в течение более длительного периода, либо на неопределенный срок. Сохраните запись этого токена обновления в БД.
всякий раз, когда пользователь "активен", выдайте новый токен аутентификации каждый раз (действителен в течение 15 минут каждый раз). Если пользователь не активен более 15 минут, а затем делает запрос (поэтому использует истекший jwt), проверьте правильность токена обновления. Если он действителен (включая проверку db), то выдайте новый токен аутентификации.
Если a пользователь "выходит" либо на устройстве, либо через веб-сайт, затем уничтожает оба токена обновления доступа на стороне клиента и, что важно, отменяет действительность используемого токена обновления. Если пользователь меняет пароль на любом устройстве, отмените все маркеры обновления, заставив их снова войти в систему, как только истечет срок действия маркера доступа. Это оставляет "окно неопределенности", но это неизбежно без попадания в БД каждый раз.
использование этого подхода также открывает возможность для пользователей возможность "отозвать" доступ к определенным устройствам, если это необходимо, как видно из многих основных веб-приложений.
Я не уверен, что я что-то упускаю здесь, но я нахожу, что принятый ответ сложнее, чем необходимо.
Я вижу, что db должен быть поражен, чтобы проверить или аннулировать токен для каждого запроса api, однако общий процесс мог быть проще, поскольку я вижу вещи здесь.
всякий раз, когда JWT создается, т. е. во время входа в систему или изменения/сброса пароля, вставьте jwt с userid в таблицу и поддерживайте JTI (номер uuid в основном) для каждого jwt. Тот же jti также входит в полезную нагрузку jwt. Эффективно jti однозначно идентифицирует jwt. Пользователь может иметь несколько jwts одновременно, когда учетная запись доступна с нескольких устройств или браузеров, в этом случае jti дифференцирует устройство или пользовательский агент.
таким образом, схема таблицы будет, jti / userId. (и первичный ключ, конечно)
для каждого api проверьте, находится ли jti в таблице, что означает, что JWT является допустимым.
когда пользователь изменяет или сбрасывает пароль, удалите все jti этого идентификатора пользователя из БД. Создайте и вставьте новый jwt с новым jti в таблицу. Это аннулирует все сеансы со всех других устройств и браузеров, кроме того, который изменил или сбросил пароль.
когда пользователь logsout, удалить, что особенно СТИ этого пользователя, но не все. Будет один вход, но не один выход из системы. Поэтому, когда пользователь выходит из системы, он не должен выйти из всех устройств. Однако, удаление все упс выход из всех устройств тоже.
таким образом, это будет одна таблица и никаких сравнений дат. Также это будет тот же случай, если используется токен обновления или нет.
однако, чтобы минимизировать помехи БД и возможные задержки, использование кэша, безусловно, поможет облегчить вещи на фронте времени обработки.
Примечание: пожалуйста, причину, если Вы вниз голосования.
Если пользователь меняет свой пароль, вы попадете в БД там. Но не хотите попасть в БД для авторизации?
Я нашел преимущества хранения строки для каждого пользователя, а глобальная общая строка, хэшированная вместе, дает нам максимальную гибкость с нашей реализацией JWT. В этом конкретном случае я бы сохранил хэш пароля для использования с глобальной строкой и хэшировал их вместе для секрета JWT.
Я согласен исключительно с ответом @gopinath просто хочу добавить одну вещь, что вы также должны удалить время смены пароля, когда все ваши токены истекли, например, предположим, что вы установили 3-дневное время истечения срока действия для каждого токена истекает сейчас, а не просто нормальное сохранение времени смены пароля в базе данных вы также можете установить его срок действия 3 дня, потому что, как очевидно, токены до этого будут истекать, поэтому не нужно проверять каждый токен снова, время пароля или нет