Нужно ли иметь sh refre sh токен, хранящийся в базе данных?

Question

Я работаю над веб-приложением, которое использует Go в бэкэнде и аутентификации на основе JWT. Когда пользователи входят в систему, я отправляю им токен доступа с коротким сроком действия и токен refre sh с длительным сроком действия. Оба этих токена включают username в качестве полезной нагрузки. Они созданы с разными секретами. Мой вопрос о выходе из системы. Когда пользователь отправляет запрос на выход из системы, я хочу аннулировать его токен refre sh, чтобы он был необходим для повторного входа в систему после выхода из системы. Для решения я собираюсь сохранить этот refre sh токен в таблице черного списка в моей базе данных. Мой вопрос заключается в том, что мне нужно иметь sh этот refre sh токен перед сохранением его в базе данных. Спасибо.

Answer 1

Одна из стандартных претензий JWT ( RF C 7519 §4.1.7 ) - "jti", которая является уникальным идентификатором токена. Если вы включите уникальный идентификатор в свой токен refre sh, то этого достаточно для сохранения претензий "jti" и "exp" (expiration) в базе данных. (Я бы по умолчанию использовал ("github.com/satori/go.uuid").NewV4 для генерации "jti" в качестве случайного UUID, и это внутренне поддерживается генератором случайных чисел "crypto/rand".)

Теперь, если вам предоставляется токен refre sh, вы можете выполнять обычные проверки его правильности подписи и срока действия, а затем искать "jti" в базе данных. Если его нет в черном списке, его можно использовать повторно. Вам нужно всего лишь сохранить "exp" в базе данных, чтобы знать, когда безопасно очищать записи. Поскольку "jti" - это просто случайный идентификатор, вы не можете вернуться от "jti" к какой-либо идентифицируемой информации, поэтому нет особой необходимости в sh или шифровании.

Если вы не у меня нет "jti" и он не может быть добавлен, я бы, вероятно, либо имел sh токен, либо просто сохранил бы копию требований. Частично это по космическим причинам, а частично вы не хотите хранить что-то, что на самом деле является действительным удостоверением. Храните достаточно информации, чтобы вы могли однозначно идентифицировать токен; возможно, "sub" и "exp" времени вместе - достаточно информации (если два токена, выданных одному и тому же субъекту, истекающие в одну и ту же секунду, неразличимы).