Архитектура JWT для нескольких пользователей?

В большинстве примеров всегда учитывается только один пользователь, использующий систему в учебных пособиях JWT/Flask. Я хочу понять это на многопользовательском уровне, но не могу найти правильные ресурсы.

Допустим, у нас есть следующий секретный ключ:

app.config['SECRET_KEY'] = 'randomkey'

Два вопроса:

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

jwt
person STOPIMACODER    schedule 13.09.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

В данном случае этот ключ является ключом подписи JWT. Он также может отличаться от настройки секретного ключа flask (см. документы flask). Он не используется для шифрования, поэтому он не предназначен для совместного использования между сервером и пользователями. Его роль состоит в том, чтобы предоставить серверу доказательство того, что содержимое JWT было сгенерировано самим сервером: это доказательство целостности.

Знание этого ключа означает наличие права выдавать JWT от имени приложения, злоумышленники могут выдавать себя за серверы или делать запросы с некоторыми измененными утверждениями, например, притворяясь другими пользователями. Это означает, что эти ключи вполне разумны с точки зрения безопасности.

Получается, что 1 приложение : 1 ключ, с некоторыми замечаниями

  1. Этот ключ теоретически никогда не должен меняться: если в момент времени T1 KEY=x пользователь может войти в систему и получить JWT, подписанный с KEY=x. при T2 KEY=y пользователь вызовет некоторый API, используя предыдущий JWT, и сервер попытается проверить (подпись (полезная нагрузка, x), y). Таким образом, каждый пользователь автоматически выйдет из системы.

  2. Несмотря на 1. Хорошо бы повернуть ключ. В этом случае система аутентификации должна сохранить буфер старых ключей и использовать их для проверки самого старого JWT. Поскольку JWT должен быть недолговечным, может быть полезно установить время ротации больше, чем время истечения срока действия JWT, и просто сохранить последний использованный ключ вместе с текущим.

  3. Этот ключ является секретом, и им следует управлять точно так же, как и другими секретами. Помимо ужасных подходов, таких как сохранение открытого текста в коде/конфигурации, существуют секретные менеджеры от облачных провайдеров или секреты kubernetes, если вы используете последние, а также секретные менеджеры из инструментов управления конфигурацией (salt, ansible) или Хранилище Hashicorp, которое представляет собой специализированный механизм хранения важных данных. В любом случае, если вы работаете в структурированной организации, это больше забота команды инфраструктуры/безопасности.

person Carmine Ingaldi    schedule 13.09.2020