Безопасность REST API: HMAC / хеширование ключей против JWT

16

Я только что прочитал эту статью , которой несколько лет, но в которой описан умный способ защиты ваших REST API. По существу:

  • Каждый клиент имеет уникальную пару открытый / закрытый ключ
  • Только клиент и сервер знают закрытый ключ; оно никогда не отправляется по проводам
  • При каждом запросе клиент принимает несколько входных данных (сам запрос, текущую метку времени и закрытый ключ) и запускает их через функцию HMAC, чтобы создать хэш запроса
  • Затем клиент отправляет на сервер обычный запрос (который содержит открытый ключ) и хэш
  • Сервер ищет закрытый ключ клиента (на основе предоставленного открытого ключа) и выполняет некоторую проверку метки времени (которую я, правда, не понимаю), которая проверяет, что запрос не является жертвой атаки воспроизведения
  • Если все хорошо, то сервер использует закрытый ключ и ту же функцию HMAC для генерации собственного хэша запроса
  • Затем сервер сравнивает оба хэша (тот, который был отправлен клиентом, и тот, который он сгенерировал); если они совпадают, запрос аутентифицируется и разрешается продолжить

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

security rest authentication keys hmac smeeb
источник
1
Lol ... Я просто хотел задать тот же самый вопрос и наткнулся на ваш. Одна из первых вещей, которые я нашел в аутентификации без сохранения состояния, была от AWS: docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/… , и реализовал что-то вроде этого massimilianosciacco.com/… . Потом я нашел JWS / JWT, и это как-то похоже. Но, насколько я понимаю, JWT - это стандарт, а другие решения, описанные выше, - это некоторые пользовательские реализации (не стандартизированные). Кто-то поправит меня, если я ошибаюсь.
nyxz
2
Приятно знать, что я не единственный, кто беспокоится о таких деталях! JWT, конечно, чувствует себя похожим, и бонус в том, что он стандартизирован. Мне просто интересно, как это (в плане безопасности) с этим пользовательским решением HMAC.
Смеб

Ответы:

7

Давайте начнем с очень простого ответа.

JWT (как используется в контексте OAuth и OpenID) не требует общих секретов между клиентом и API. Есть 3 компонента и пары из 2, каждый из которых имеет общий секрет: клиентский <-> сервер идентификации, API идентификации сервера <->.

Это переносит большую сложность от API к серверу идентификации, API просто должен проверить, что токен был выдан сервером идентификации и не был закален. Чтобы убедиться, что API проверяет, является ли JWT-подпись действительной с известным единым общим секретом между сервером идентификации и API. Это оно!

То, как сервер идентификации проверяет личность пользователя, может сильно различаться (во многих случаях это старая пара имя пользователя + пароль по TLS-соединению), но это не влияет на ваш API.

Конфиденциальность и безопасность сообщения и самого токена при использовании JWT обрабатываются TLS, JWT не знает о таких проблемах.

Патрик
источник