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

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

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

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

— smeeb
источник

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

— nyxz

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

— Смеб

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

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

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

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

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

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