Захист API REST: HMAC / хешування ключів проти JWT

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

У кожного клієнта є унікальна пара відкритих та приватних ключів
Тільки клієнт і сервер знають приватний ключ; він ніколи не надсилається по дроту
З кожним запитом клієнт приймає кілька входів (сам запит, поточна мітка часу та приватний ключ) і запускає їх через функцію HMAC для створення хешу запиту
Потім клієнт відправляє звичайний запит (який містить відкритий ключ) та хеш на сервер
Сервер шукає приватний ключ клієнта (на основі наданого відкритого ключа) і перевіряє часові позначки (що, правда, я не розумію), що підтверджує, що запит не є жертвою повторної атаки
Якщо все добре, сервер використовує приватний ключ і ту саму функцію HMAC, щоб генерувати власний хеш запиту
Потім сервер порівнює обидва хеші (той, який надіслав клієнт, а також той, який він створив); якщо вони відповідають, запит перевіряється автентичністю та дозволяється продовжувати

Потім я натрапив на JWT , який звучить дуже схоже. Однак перша стаття взагалі не згадує JWT, і тому мені цікаво, чи JWT відрізняється від вищезазначеного рішення про авторство, і якщо так, то як.

— смех
джерело

Лол ... Я просто хотів задати таке саме запитання і натрапив на твій. Одне з перших речей, які я дізнався про автентифікацію без громадянства, було від AWS: docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/… , і реалізував щось подібне до цього massimilianosciacco.com/… . Тоді я знайшов JWS / JWT, і це якось схоже. Але наскільки я розумію, JWT є стандартом, а інші описані вище рішення - це деякі спеціальні реалізації (не стандартизовані). Хтось мене виправить, якщо я помиляюся.

— nyxz

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

— smeeb

Почнемо це з дуже базової відповіді.

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

Це переміщує найбільшу складність з API на сервер ідентифікації, API просто повинен перевірити, що маркер виданий сервером ідентифікації та не був загартований. Щоб переконатися, що API перевіряє, чи є JWT-підпис дійсним з відомим єдиним загальним секретом між сервером ідентифікації та API. Це воно!

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

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

— Патрік
джерело