#jwt #basic-authentication #refresh-token
#jwt #basic-аутентификация #refresh-token
Вопрос:
Я использую токены JWT и обновления для аутентификации. На данный момент у меня есть отношение «один ко многим» между токенами user и refresh. Я отменяю токен обновления при выходе пользователя из системы, но не удаляю. Это вызывает более одного токена обновления на пользователя, и это создает много токенов обновления в базе данных. И это вызывает проблемы с производительностью. Поэтому я думаю установить взаимно однозначные отношения между пользователем и токеном обновления. Я не вижу смысла, чтобы у пользователя было более одного токена обновления (отозванные токены, активные токены против каждого пользователя). Как вы думаете, есть ли какая-либо причина сохранять старые токены обновления для пользователя в таблице токенов обновления? Также, как вы думаете, я должен индексировать токены обновления
Комментарии:
1.
and this makes a lot of refresh tokens on database… ваша первая проблема заключается в том, что вы храните свой JWT в базе данных. Зачем вы их вообще храните? Если вам необходимо сохранить, вы должны использовать кеш.2. Я не сохраняю jwt, я сохраняю токены обновления
3. Тот же аргумент. Почему вы храните токены обновления?
4. Разве не в этом весь смысл? вы сохраняете токены обновления и находите идентификатор пользователя в этих токенах обновления, точно так же, как сеансы
5. @geforce Вы упускаете из виду весь смысл использования JWT. Вся мотивация использования JWT заключается в том, что состояние сеанса вашего пользователя существует за пределами вашего сервера приложений. Когда пользователь представляет токен доступа или обновления, этот JWT сам по себе в идеале содержит достаточно информации, чтобы ваш сервер мог принять решение о том, следует ли его учитывать или отклонять. Хорошей аналогией, возможно, более знакомой вам, было бы предъявление паспорта на таможне. Сам паспорт содержит ваши перемещаемые учетные данные.
Ответ №1:
Я также использую аутентификацию jwt, но я не храню токены в базе данных..
В этом весь смысл jwt, что пока вы используете свой секретный ключ для их создания, ваш секретный ключ используется для их подписи таким образом, что в следующий раз, когда пользователь придет с токеном, при декодировании вы узнаете данные пользователя, а затем авторизуете данного пользователя на данные пользовательские ресурсы.
Что я предлагаю, удалите токены из базы данных и создайте метод, который проверяет действительность токенов путем декодирования токена. Это связано с тем, что вы увеличиваете задержку, выполняя проверку сравнения между полученным токеном и тем, что находится в базе данных, в то время как вы могли бы просто его декодировать (я предположил, что вы выполняете сравнение так же, как собственные методы токенов). ==> Вашей базе данных это понравится.
Кроме того, имейте один и только один токен обновления. Всякий раз, когда создается новый токен обновления, пометьте старый как недействительный и выдайте новый. Во-первых, это более безопасно, потому что даже если злоумышленник получил токен обновления, при выдаче нового старый становится бесполезным.
Я не хочу говорить об индексации базы данных с помощью токенов, поскольку я полагаю, что вы не собираетесь использовать базу данных с jwts…
Для получения дополнительной информации, пожалуйста, прочитайте это
Комментарии:
1. я думаю, что я не выразился ясно, извините за это. я не сохраняю jwt в базе данных, я сохраняю токены обновления. «Что я предлагаю, удалите токены из базы данных и создайте метод, который проверяет действительность токенов путем декодирования токена. .» я уже делаю то, что вы говорите здесь. если вы храните только один токен обновления, как вы отмечаете старый? когда есть только один?
2. Токены обновления — это JWT, и этот ответ в основном правильный 1.
3. Мне очень жаль, я не знал, что JWT означает токен обновления, я думал, что это означает токен доступа. Я сохраняю свои токены обновления в базе данных. Мой вопрос заключается в том, что один токен обновления для каждого пользователя — это нормально, или мне нужно установить связь «многие ко многим», потому что там, где я читаю примеры этой системы аутентификации, они используют связь «многие ко многим» между пользователем и токеном обновления. При создании нового токена обновления старый становится недействительным или при выходе пользователя из системы старый токен обновления отменяется. Но я не понял логики хранения более одного токена обновления для одного пользователя, потому что это можно сделать и с одним токеном.
4. Ага, @geforce, JWT для токенов в вашей схеме разделены на два…. Токены обновления и доступа. Токены обновления используются для
refreshтокенов доступа (которые предоставляют пользователю доступ к их авторизованным объектам)… Таким образом, оба токена обновления и доступа являются jwt5. Итак, есть ли какие-либо недостатки в том, чтобы сделать отношения пользователя и повторного открытия взаимно однозначными?