#authentication #session #jwt #jwt-auth
#аутентификация #сеанс #jwt #jwt-auth
Вопрос:
Прочитав несколько руководств по использованию JWT для входа / выхода из системы на веб-сайте / в приложении, все они, похоже, предполагают этот механизм хранения некоторой информации о пользователе (например, id, имя и т. Д.) В данных полезной нагрузки, например (с официального сайта):
{
"id": 4,
"name": "John Doe",
"admin": true
}
а затем сохраняем токен где-нибудь в интерфейсе и включаем его для каждого запроса (например, в заголовок авторизации после предъявителя). Но тогда эта форма отслеживания вошедшего в систему пользователя может привести к серьезному состоянию гонки для операций, которые изменяют данные полезной нагрузки, такие как вход в систему и выход из системы. Вот простой сенарио: предположим, что пользователь с идентификатором 4 уже вошел в систему, а токен, содержащий полезную нагрузку идентификатора пользователя, уже сохранен во внешнем интерфейсе. Теперь переднее приложение отправляет некоторые запросы, и следующие действия выполняются в хронологическом порядке:
| Экшен | Токен JWT, хранящийся в интерфейсе | статус входа в систему |
|---|---|---|
| Интерфейс отправляет запрос с запросом на какое-либо произвольное действие | {id:4} | вход в систему |
| Интерфейс отправляет запрос B с запросом на выход из системы | {id:4} | вход в систему |
| Приходит ответ на запрос B, содержащий токен с полезной нагрузкой {}, что означает, что пользователь вышел из системы | {} | выход из системы |
| Ответ на запрос A содержит токен с полезной нагрузкой {id: 4} (такой же, как и соответствующий запрос) | {id:4} | вошел в систему!!!!! |
Итак, когда пользователь вышел из системы, он снова вошел в систему без предварительного уведомления! Это потому, что токен ответа запроса A перезаписывает токен ответа B! В общем, этот децентрализованный механизм хранения любой информации о полезной нагрузке jwt может привести к состоянию гонки, поскольку входящие токены могут перезаписывать друг друга, и изменения (например, статус входа) могут быть потеряны. Я думаю, нам нужно сделать больше либо на интерфейсе, либо на сервере. Я что-то упускаю в JWT?
Ответ №1:
Токен JWT генерируется и возвращается только в ответ на запрос входа в систему. При остальных вызовах (action) токен JWT отправляется только на серверную часть, новый токен не получен и не обновляется на стороне клиента. При выходе из системы токен на стороне клиента очищается.
Условие гонки возникает только в том случае, если между запросами входа и выхода тогда.
В идеале вы не можете удалить токен JWT, поскольку мы не храним его на серверной части. Удаление действительно выполняется только по истечении срока его действия. Таким образом, модифицированная версия этой модели будет поддерживать список всех вышедших из системы неиспользованных токенов в серверной части для повышения безопасности. Это также может помочь избежать указанного условия гонки.
Комментарии:
1. Да, как вы сказали, нам нужно выполнить еще несколько действий, например, удалить токен во внешнем интерфейсе… но тогда это означает, что JWT не является местом для хранения информации о сеансе, поскольку они могут измениться. И это противоречит примеру официального веб-сайта JWT, где они хранят имя пользователя (John Doe, как обычно) в токене JWT. Что, если пользователь обновит свое имя?
2. a не при удалении, если токен JWT хранится в cookie, управляемом сервером (то есть cookie с установленным флагом httponly), то удаление может произойти только тогда, когда в ответе на выход из системы содержимое cookie, сохраненное JWT, пустое