Блог

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

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

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

Два вопроса:

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

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

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

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

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

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

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