Должен ли я хранить свои заявки пользователей в токене JWT?

18

Я использую токены JWT в заголовках HTTP для аутентификации запросов к серверу ресурсов. Сервер ресурсов и сервер аутентификации - это две отдельные рабочие роли в Azure.

Я не могу определиться, стоит ли мне сохранять заявки в токене или прикреплять их к запросу / ответу каким-либо другим способом. Список утверждений влияет на отображение элементов пользовательского интерфейса на стороне клиента, а также на доступ к данным на сервере. По этой причине я хочу убедиться, что заявки, полученные сервером, являются подлинными и проверены перед обработкой запроса.

Примеры заявлений: CanEditProductList, CanEditShopDescription, CanReadUserDetails.

Причины, по которым я хочу использовать для них токен JWT:

  • Лучшая защита от редактирования претензий на стороне клиента (например, взлом списка претензий).
  • Не нужно искать претензии по каждому запросу.

Причины, по которым я не хочу использовать токен JWT:

  • Сервер аутентификации должен знать список заявок, ориентированный на приложения.
  • Токен становится единственной точкой взлома.
  • Я читал несколько вещей о том, что токены JWT не предназначены для данных уровня приложения.

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

ПРИМЕЧАНИЕ. Я буду использовать HTTPS для всех запросов API, поэтому мне кажется, что токен будет «достаточно безопасным». Я использую AngularJS, C #, Web API 2 и MVC5.

security http authentication authorization Astravagrant
источник
читая это сейчас .... и хотел бы обновление, если вы можете. Мне было бы интересно, что вы сделали, так как я сталкиваюсь с тем же ... думать, и мне не хватает, как некоторые части предназначены для работы. пользователь получает авторизационный токен, но как тогда претензии должны переноситься ... не могли бы вы объяснить свои выводы ... как это, вероятно, помогло бы мне.
Seabizkit

Ответы:

7

Я храню только утверждения идентификатора (идентификатор пользователя и т. Д.) (Зашифрованные) в моем jwt.

Затем, когда я получаю токен на сервере (API), я могу выполнить поиск на стороне сервера (db или вызов локальной сети API) и извлечь все ассоциации с идентификатором пользователя (приложения, роли и т. Д.)

Однако, если вы хотите добавить больше в jwt, просто будьте осторожны с размером, поскольку он, вероятно, будет отправляться при каждом запросе, но обязательно шифруйте конфиденциальные данные заявки.

wchoward
источник
Приветствия, DL. Вы кешируете роли и т. Д. На сервере API или просто дважды нажимаете на БД каждый раз, когда получаете запрос? (т.е. один раз для ролей и один раз для фактических запрашиваемых данных). Если вы кешируете его, мне будет интересно узнать, какой метод вы используете. Кроме того, вы имеете в виду, что вы продолжаете шифровать идентификатор пользователя «внутри» уже зашифрованного токена? Благодарю.
Остравагрант
1
Я еще не настолько углубился в мою реализацию :), но да, я думал об использовании сервера кэширования, чтобы я не попадал в базу данных так часто, и если роль меняется, кеш можно удалить, чтобы позволить новому Роль запрашивается для загрузки сохраненного кэша. В моем случае я бы, вероятно, использовал elstache Amazon AWS, который основан на открытом memcached, но более прост в настройке и использовании.
wchoward
Я также думаю, что лучше получить всю необходимую информацию на сервере ресурсов, а не хранить ее в токене.
Матеуш Мигала
поэтому для каждого запроса вы получаете роли пользователей ... претензии ..., не могли бы вы указать мне статью или что-то, что показывает, что это осуществимо. в настоящее время я использую сессию, но ищу лучший способ сделать что-то, но поиск по каждому запросу не кажется правильным?
Seabizkit
3

Похоже, что аутентификация (кто пользователь) и авторизация (что пользователь может делать) не так четко разделены, как хотелось бы.

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

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

Примечание: оба JWT должны быть подписаны разными ключами.

Плюсы:

  • Аутентификация и авторизация управляются отдельно.
  • Сервер ресурсов не должен искать авторизацию для каждого запроса.
  • Пользовательский интерфейс имеет право видеть авторизацию, но не редактировать ее.

Против:

  • Клиент должен обрабатывать два токена вместо одного.
  • Добавление сервера авторизации добавляет другую движущуюся часть для управления.
Чед Кларк
источник
1
Не забывайте, что даже когда вы проверяете авторизацию в пользовательском интерфейсе, вы все равно должны проверять авторизацию на стороне сервера, когда приходит запрос.
Чед Кларк