Де розмістити ключ API: спеціальний заголовок HTTP VS заголовок авторизації за спеціальною схемою

Я розробляю API REST за допомогою авторизації / автентифікації за допомогою ключа API.

Я спробував розібратися, яке найкраще місце для цього, і з’ясував, що багато людей пропонують використовувати власний заголовк HTTP ProjectName-Api-Key, наприклад, наприклад:

ProjectName-Api-Key: abcde

але також можливо і ідеологічно правильно використовувати Authorizationзаголовок із власною схемою, наприклад:

Authorization: ApiKey abcde

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

Яким способом ви б хотіли надіслати ключ API?

— РоманГ
джерело

Проекти під моїм керівництвом використовують Authorization: Bearer <token>заголовок, і з цим ніколи не було жодної проблеми. Маркери - JWT s.

— Енді

@DavidPacker Як я розумію, Bearerсхема використовується виключно з oAuth2. Застосування його окремо від oAuth звучить як неправильне використання. Чому правильно використовувати цю схему, якщо немає oAuth? До речі, у мене виникли проблеми з вибором типу авторизації для мого API. API буде доступний лише для однієї надійної служби, тому я дослідив потік облікових даних клієнта oAuth2 і не знайшов ніякої користі порівняно з ApiKey в моєму випадку.

— RomanG

@DavidPacker Тоді я зрозумів, що авторизація ApiKey може розглядатися як дійсна реалізація oAuth, якщо ApiKeyвона буде перейменована та інтерпретована як Access Tokenнадана клієнту без закінчення терміну дії. Це свого роду філософський аспект, я вирішив не приводити складних визначень, якщо мій випадок можна описати простими словами, і вирішив просто назвати його "ApiKey". Якщо ваш протокол реалізує стандарт oAuth, я можу погодитись на використання Bearer, але це не так, я думаю, цю схему неможливо застосувати.

— RomanG

Ви занадто обмежуєте себе. Споживач API не може менше дбати, чи реалізували ви OAuth чи ні. Те, що їх хвилює, - це безпека маркера, те, що видає маркер, і що вони можуть отримати належну автентифікацію. Вони рекомендують використовувати носій прямо в документації JWT . JWT ідеально відповідає схемі Bearer, і я не міг більше рекомендувати JWT. Вони ідеально підходять для програм REST, оскільки ви можете перевірити автентифікацію користувача, навіть не потрапляючи в базу даних, якщо тільки вам не потрібна функція відкликання токенів.

— Енді

(заїжджайте на) ... будь ласка, не забудьте знати, що клавіші api - це спільні секрети, які зазвичай діляться між налаштованою стороною та аутентифікатором, не повідомляти особу чи авторизацію. Заявлений іншим способом, вони призначені лише для того, щоб ініціювати рукостискання безпеки, а не представляти результат аутентифікації. Клавіша api повідомляє ваші повноваження щодо ідентифікації себе проти надійного автентифікатора системи. Використовувати клавішу як маркер для контролю безпечного доступу до ресурсів - погано дзюджу

— К. Алан Бейтс

Якщо ви використовуєте Авторизацію, будьте послідовними

Деякі запевнятимуть, що наступне є непотрібним ( і не надто давно я б погодився з ними ), але в ці дні, якщо ми будемо використовувати Authorizationзаголовок, ми повинні повідомити тип жетону, тому що ключі API не є самоописовими як такі ¹ .

Чому я вважаю, що це потрібно і чому я вважаю, що це важливо? Тому що нині підтримка різних протоколів аутентифікації / авторизації стала необхідною. Якщо ми плануємо використовувати Authorizationзаголовок для всіх цих протоколів, ми повинні зробити нашу службу аутентифікації послідовною. Спосіб повідомлення того, який маркер ми надсилаємо та який протокол авторизації слід застосувати, також має міститись у заголовку.

Authorization: Basic xxxx
Authorization: Digest xxxx
Authorization: Bearer xxxx
Authorization: ApiKey-v1 xxxx
Authorization: ApiKey-v2 xxxx

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

Побоювання

Проблеми, з якими я стикався з реалізацією власних схем, були подібними до коментованих.

З іншого боку, я зрозумів, що спеціальна схема авторизації може бути несподіваною та непідтримуваною деякими клієнтами і все одно призводить до користувацького коду

Скажіть клієнтам , скажімо, бібліотекам, фреймворкам, зворотним проксі .

Переваги

Одна важлива перевага - кеш. Спільні кеші не кешуватимуть заголовок (і це добре, звичайно), якщо ви не скажете інше.

Тож Авторизація чи користувацький заголовок?

На мій досвід, реалізація власної Authorizationсхеми взяла на мене стільки ж роботи (або більше), ніж реалізація заголовків авторизованих авторизацій, з незначною різницею, що мають більше свободи дизайну та більше контролю над кешем, коли я використовую власні заголовки. Причина досить дурна, більшу частину часу я Cache-controlналаштовую на no-cacheабо no-store, що дозволяє мені робити дзвінки на сервер більш детермінованими (це важливо, якщо мова йде про стеження та тестування) незалежно від топології мережі.

^{1: Я вважаю цю відповідь дуже чіткою щодо ключів API}

— Лаїв
джерело

Використання X-небажаний 2012: stackoverflow.com/a/3561399/923720

— Darkhogg

ops! Я не знав. Відредаговано та виправлено.

— Лаїв

Перед цим питанням я думав, що більшість хтось поклав ключ API в URL-адресу, але використовував HTTPS, щоб приховати його. Приємно бачити деякі варіанти. Наприклад, дозволяє авторизації змістовної або pamameter запит: contentful.com/developers/docs/references/content-delivery-api / ...

— user949300

@ user949300 ... використання зашифрованого загального секрету (наприклад, ключ api в урі над ssl), очевидно, є більш безпечним, ніж взагалі нічого, але легко піддається підключенню, якщо він перехоплений і не забезпечує деталізації щодо ідентичності. Я ніколи не використовував api_keys для чогось іншого, крім машинного для машинного спілкування, де я співставляю загальну таємницю між довіряючими сторонами та білими ідентифікаторами машин, уповноважених діяти з цією загальною таємницею. Після виготовлення з'єднання з машини на машину оператор людини аутентифікується за допомогою інших засобів.

— К. Алан Бейтс

@K. Алан Бейтс Більшість моїх взаємодій API стосуються відносно "неважливих" речей, таких як вільний рівень геокодування, звіти про погоду тощо), де ключ API більше обмежує швидкість, ніж серйозні секрети користувачів. Отже, що стосується ОП, це залежить від того, який рівень безпеки потрібен.

— user949300