API desing - Можно ли извлекать данные пользователя из токена аутентификации?

Question

Давайте рассмотрим этот случай использования:

1) Я называю мой API для входа в конечную точку с именем пользователя и паролем, и получить мой Auth маркер, который я добавляю к каждому последовательному запросу в заголовок как Authorization: Bearer <token>.

2) Я вызываю /current-user конечную точку без параметров, только с заголовком авторизации. Сервер разрешает пользователю использовать токен и получает идентификатор пользователя из этого токена. Затем он находит пользователя по id в базе данных и возвращает его данные.

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

Не нужно ли хранить идентификатор пользователя на клиенте вместе с токеном и запросами на вызовы с использованием обоих? Например. /user?id=<stored user id> с заголовком авторизации и избавиться от конечной точки /current-user? После этого какой-то ACL на сервере определит, использовал ли токен доступ к пользователю с переданным идентификатором пользователя.

(Я также нашел, что есть JWT лексемы, но я вижу ту же проблему там. Как злоумышленником я каким-то образом удалось угадать маркер и сервер другого пользователя будет возвращать мне свои данные)

Answer 1

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

Кроме того, если ваш токен достаточно длинный и абсолютно случайный, на самом деле это не имеет никакого значения.

Посмотрите на это так: предположим, ваш токен имеет длину n, ваш идентификатор пользователя имеет длину m. Без идентификатора пользователя злоумышленник должен угадать n персонажей, в том числе она должна угадать n+m символов. Если ваш n достаточно высок, вам не нужны эти дополнительные символы. Имейте в виду, что длина идентификатора пользователя может быть намного меньше его видимой длины, если ваши идентификаторы пользователя не являются полностью случайными, поэтому добавленный m действительно может быть действительно небольшим.

Answer 2

Возможно ли использовать значки с цифровой подписью? Вы можете в основном зашифровать токен с помощью закрытого ключа клиента (или пользователя), а затем снова зашифровать пакет вместе с открытым текстом пользователя с открытым ключом сервера. Таким образом, только сервер может расшифровать пакет и разшифровать его, он знает, кто такой пользователь. Затем он может использовать открытый ключ, связанный с этим идентификатором пользователя, для дешифрования пакета и получения маркера.

Поскольку вы не предоставили много информации о приложении и скорости требуемой аутентификации или технологий, которые вы используете, сложно предоставить более подробную информацию.