Как правильней хранить и обновлять JWT для аутентификации?

Question

[Boris009]

Для токенов нужно создавать отдельную таблицу и при каждом запросе делать проверку на что?
На поиск по существованию такого токена в таблице или как-то через id пользователя, а после уже в таблице токенов сравнивать имя токена?
И при каждом запросе обновлять время жизни токена или задавать его только при создании?
Его при хранении и передаче надо как-то шифровать или это не имеет смысла и можно генерировать для веб токена ключ из любого типа набора букв и цифр?

Answer 1

[Rsa97]

Каждый JWT-токен это три блока - заголовок, полезная нагрузка и подпись. В заголовке хранится информация о самом токене (срок жизни, алгоритм подписи). Полезная нагрузка - информация приложения. Подпись - зашифрованный хэш первых двух частей. В распределённых системах выдавать токен может сервер авторизации, а использовать любой другой сервер. В таком случае подпись может быть асимметричной, закрытый ключ для подписания, открытый для проверки.

Токены выдаются парой, рабочий + обновления.

Рабочий токен выдаётся на короткое время (минуты - десятки минут). Внутри содержится срок окончания действия токена, идентификатор пользователя, его права, какая-то информация для минимизации обращений к БД по данному пользователю. Токен на сервере не сохраняется.

Токен обновления выдаётся на длительное время (часы - дни). Внутри содержится срок окончания действия токена и идентификатор пользователя для автоматической аутентификации. Токен обновления (или его идентификатор, если он есть в токене) хранится в БД вместе с идентификатором пользователя.

1. Клиент аутентифицируется/авторизуется на сервере со своим логином/паролем.
2. Сервер генерирует пару токенов, короткоживущий рабочий и долгоживущий для обновления. Токен обновления записывается в БД.
3. Клиент присылает запрос с рабочим токеном.
4. Сервер проверяет токен.
4а. Токен действительный и неистекший, сервер отвечает на запрос.
4б. Токен действительный, но истекший, сервер сообщает о необходимости обновления токена.
4в. Токен недействительный, сервер сообщает о необходимости входа по логину/паролю (на п.1).
5. Клиент присылает токен обновления.
6. Сервер проверяет токен, в том числе и в БД.
6а. Токен обновления недействительный, сервер сообщает о необходимости входа по логину/паролю (на п.1).
6б. Токен обновления действительный, но в БД отсутствует, сервер удаляет все токены обновления этого пользователя из БД и сообщает о необходимости входа по логину/паролю (на п.1).
6в. Токен обновления действительный, но просроченный, сервер удаляет этот токен из БД и сообщает о необходимости входа по логину/паролю (на п.1).
6г. Токен обновления действительный, непросроченный, в БД присутствует. Сервер удаляет этот токен из БД, генерирует новую пару, записывает новый токен обновления в БД и отправляет токены клиенту (на п.3).

Answer 2

[Nik Faraday]

Ваш токен это просто шифрованная строка и всё. Таблица под токены тоже должна быть простая, id, token и id юзера (Или кого-то другого, кому он принадлежит). Далее вы получаете откуда-то этот токен, а так же должны получить данные, кто его отправил.

Для примера, у вас юзер будет переходить куда-то по этому токену и он будет отображаться в url.

Далее вы проверяете id юзера (Или кого-то другого) и сам токен. Теперь делаете вывод, правильный ли токен был передан по url.

Другая ситуация, когда у вас нет id юзера а есть просто токен. Тогда вы можете по БД проверить, какой юзер ДОЛЖЕН был перейти по этому токену.

Воспринимайте токен как пароль