Помістіть ключ API у заголовки або URL

78

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

Оскільки API REST, моя початкова думка полягає в тому, щоб помістити цей ключ у спеціальний заголовок. Ось як я бачив, як це роблять Google, Amazon і Yahoo. З іншого боку, мій бос вважає, що API простіше використовувати, якщо ключ стає просто частиною URL-адреси тощо. " Http: //api.domain.tld/longapikey1234/resource ". Думаю, за це потрібно щось сказати, але це порушує принцип URL-адреси як простої адреси того, що ви хочете, а не того, як і чому ви цього хочете.

Чи було б вам логічно ввести ключ в URL-адресу? Або вам краще не доведеться вручну встановлювати заголовки HTTP, якщо ви пишете простий інтерфейс JavaScript для деяких даних?

— Томас Але
джерело

77

Його слід помістити в заголовок авторизації HTTP. Специфікація знаходиться тут https://tools.ietf.org/html/rfc7235

— Даррел Міллер
джерело

Я вже використовую заголовок Authorization для третьої частини - кінцевого користувача. Тобто кінцевому користувачеві потрібно увійти до програми, щоб отримати повний доступ до вмісту.

— Thomas Ahle

5

@Thomas Кількість параметрів, які можна вставити в заголовок auth, не обмежена. Подивіться на OAuth, він містить близько 8 різних значень параметрів у заголовку.

— Даррел Міллер,

1

Оновлення посилання - Зараз RFC 7235 станом на червень 2014 року

— Стівен П

Я не кажу, що ти помиляєшся, але коли ти кажеш " повинно бути " - звідки ти знаєш? Хто каже? (Я знайшов це запитання, тому що, здається, Apache часто

— зачищає

2

@JAAulde Я докладаю деталей тут bizcoder.com/where-oh-where-does-the-api-key-go Мені буде цікаво, якщо у вас є посилання на проблему Apache.

— Даррел Міллер,

67

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

— стояти
джерело

1

На додаток до ваших зауважень щодо публічного розголошення URL-адреси, URL-адреса та вбудований ключ API будуть видимими всім адміністраторам мережі з доступом до маршрутизатора, корпоративного проксі-сервера, кешування та ін.

— Адам Кавінес

4

@AdamCaviness Не з HTTPS, який у будь-якому випадку повинні реалізовувати всі API. URL-адреса зашифрована. Як адміністратор ви можете бачити лише пошук у DNS та IP-адресу, з якою спілкувався, а не вміст. І це в стороні, я погоджуюсь з stand

— nickdnk

1

@nickdnk, це правда. Що стосується HTTPS, то навіть тоді повні URL-адреси залишаються в історії браузера! Веселі речі. Я не шанувальник чогось чутливого в URL-адресі.

— Adam Caviness

@AdamCaviness Так, у цьому сенсі. Я розумів це так, ніби хтось міг читати трафік, якщо він мав доступ до маршрутизатора.

— nickdnk

І цей API є хорошим прикладом того, як не робити pipedrive.com/en/api .

— Джон Джон Піхлер,

13

Краще використовувати API-ключ у заголовку, а не в URL-адресі.

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

Ви можете використовувати ключ API у заголовку двома способами

Основна авторизація:

Приклад із смужки:

curl https://api.stripe.com/v1/charges -u sk_test_BQokikJOvBiI2HlWgH4olfQ2:

curl використовує прапор -u для передачі основних автентифікаційних даних (додавання двокрапки після ключа API заборонить йому запитувати пароль).

Спеціальний заголовок

curl -H "X-API-KEY: 6fa741de1bdd1d91830ba" https://api.mydomain.com/v1/users

— Фізер-хан
джерело

1

Чому X-API-KEY? Це X свого роду специфікація HTTP для користувацьких заголовків?

— Джон Джон Піхлер,

1

stackoverflow.com/questions/3561381/…

— Фізер-хан,

2

Я б не став клавішу в url, оскільки це порушує цей вільний "стандарт", тобто REST. Однак якщо б ви це зробили, я б розмістив його у частині "користувач" URL-адреси.

наприклад: http: //me@example.com/myresource/myid

Таким чином його також можна передавати як заголовки з basic-auth.

— Адам Вагнер
джерело

5

Примітка 1) це просто скорочення базової автентифікації, 2) не всі HTTP-клієнти будуть його вшановувати, і 3) принаймні один основний браузер покаже попередження про фішинг.

— user359996

@ user359996 Окуляри. У відповідь: 1) Я ухилився від цього у своєму останньому реченні, 2) Це згадується у стандарті ( tools.ietf.org/html/rfc3986 ), отже, це вина клієнта, 3) Я не знав про це , хоча я вважаю, що це має сенс, мені цікаво, чи все ще це так, коли використовується як api-дзвінок (XHR). Нарешті, питання полягало в тому, щоб спокійно включити auth-info до url-адреси, і, я думаю, я відповів на це.

— Адам Вагнер,

1

передача ключа параметрів api у параметрах ускладнює клієнтам зберігати свої API-ключі в секреті, вони, як правило, регулярно витікають ключі. Кращий підхід - передати його в заголовок URL-адреси запиту. Ви можете встановити заголовок ключа користувача у своєму коді. Для тестування URL-адреси вашого запиту ви можете використовувати програму Postman у google chrome, встановивши заголовок ключа користувача на ваш api-ключ.

— himanshu_chawla
джерело

1

Як ключі api в параметрах змушують користувачів просочувати свої ключі?

— Heinzlmaen