Поместите ключ API в заголовки или URL

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

Поскольку API - это REST, я изначально решил поместить этот ключ в настраиваемый заголовок. Я видел, как это делают Google, Amazon и Yahoo. Мой босс, с другой стороны, считает, что API легче использовать, если ключ становится просто частью URL-адреса и т. Д. "http://api.domain.tld/longapikey1234/resource ". Думаю, об этом есть что сказать, но это нарушает принцип URL-адреса как простого адреса того, что вы хотите, а не того, как и почему вы этого хотите.

Считаете ли вы логичным поместить ключ в URL-адрес? Или вам не нужно вручную устанавливать HTTP-заголовки, если вы пишете простой интерфейс javascript для некоторых данных?


authentication http url rest api-key
person Thomas Ahle    schedule 01.04.2011    source источник

Ответы (5)


arrow_upward
81
arrow_downward

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

person Darrel Miller    schedule 01.04.2011
comment
Заголовок Authorization я уже использую для третьей части - конечного пользователя. То есть конечному пользователю необходимо войти в приложение, чтобы получить полный доступ к контенту. - person Thomas Ahle; 02.04.2011
comment
@Thomas Нет ограничений на количество параметров, которые вы можете поместить в заголовок auth. Посмотрите на OAuth, у него в заголовке около 8 разных значений параметров. - person Darrel Miller; 02.04.2011
comment
Обновление ссылки - теперь это RFC 7235 по состоянию на июнь 2014 г. - person Stephen P; 01.12.2014
comment
Я не говорю, что вы ошибаетесь, но когда вы говорите Так и должно быть - откуда вы знаете? Кто говорит? (Я нашел этот вопрос, потому что кажется, что Apache часто удаляет заголовок авторизации перед выполнением PHP) - person JAAulde; 08.10.2015
comment
@JAAulde Подробности здесь, bizcoder.com/ where-oh-where-does-the-api-key-go Мне было бы интересно, есть ли у вас какие-либо ссылки на проблему с Apache. - person Darrel Miller; 08.10.2015
comment
@DarrelMiller спасибо за ссылку. Я согласен, что лучше использовать заголовки, чем строку запроса URL (или псевдопуть и т. Д.), Но я надеялся, что от авторитетного органа будет дано какое-то определенное указание относительно того, какой заголовок следует использовать. Моя проблема с Apache в настоящее время носит анекдотический характер, поэтому у меня нет ссылок, которые можно было бы предложить взамен. Сейчас я склоняюсь к использованию чего-то вроде X-API-KEY. - person JAAulde; 08.10.2015
comment
@DarrelMiller Оформить заказ в коде для Symfony HTTP Foundation: https://github.com/symfony/http-foundation/blob/master/ServerBag.php#L46-L58 - person JAAulde; 08.10.2015
comment
@JAAulde Ну, есть RFC 7235, который представляет собой полную спецификацию того, как выполнять HTTP-аутентификацию и единственный вариант, который он представляет, - это использование заголовка авторизации. - person Darrel Miller; 08.10.2015
comment
@JAAulde и ссылка на github действительно говорят, что это модуль php-cgi, который не передает основной заголовок auth, а не сам Apache. Вероятно, это связано с тем, что php-cgi, вероятно, сам выполняет авторизацию и не хочет передавать в приложение пароли в виде открытого текста. - person Darrel Miller; 08.10.2015

arrow_upward
71
arrow_downward

Если вам нужен аргумент, который может понравиться начальнику: подумайте, что такое URL-адрес. URL-адреса являются общедоступными. Люди копируют и вставляют их. Они делятся ими, они помещают их в рекламу. Ничто не мешает кому-то (сознательно или нет) рассылать этот URL-адрес для использования другими людьми. Если ваш ключ API находится в этом URL-адресе, он есть у всех.

person stand    schedule 02.04.2011
comment
Помимо ваших замечаний о публичном раскрытии URL-адреса, URL-адрес и встроенный ключ API будут видны всем сетевым администраторам, имеющим доступ к маршрутизатору, корпоративному прокси-серверу, кэширующему серверу и т. Д. - person Adam Caviness; 21.08.2012
comment
@AdamCaviness Не с HTTPS, который все API должны реализовать в любом случае. URL зашифрован. Как администратор вы можете видеть только поиск DNS и IP-адрес, с которым осуществляется обмен данными, но не содержимое. Помимо этого, я согласен с позицией - person nickdnk; 12.01.2016
comment
@nickdnk, это правда. Что касается HTTPS, то даже тогда полные URL-адреса остаются в истории браузера! Веселая штука. Я не сторонник того, чтобы в URL было что-то деликатное. - person Adam Caviness; 12.01.2016
comment
@AdamCaviness Да, в этом смысле. Я так понял, как если бы кто-то мог читать трафик, если бы у него был доступ к роутеру. - person nickdnk; 12.01.2016
comment
И этот API - хороший пример того, как не делать pipedrive.com/en/api. - person John John Pichler; 15.11.2016
comment
Ключ API в URL-адресе также означает, что он может попадать в различные журналы. - person Craig; 13.02.2018

arrow_upward
15
arrow_downward

Лучше использовать API Key в заголовке, а не в 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
person Fizer Khan    schedule 24.02.2015
comment
Почему X-API-KEY? Является ли этот X своего рода спецификацией HTTP для пользовательских заголовков? - person John John Pichler; 15.11.2016
comment
stackoverflow.com/questions/3561381/ - person Fizer Khan; 16.11.2016

arrow_upward
2
arrow_downward

Я бы не стал указывать ключ в URL-адресе, поскольку он нарушает этот свободный «стандарт», то есть REST. Однако, если бы вы это сделали, я бы поместил его в «пользовательскую» часть URL-адреса.

например: http://[email protected]/myresource/myid

Таким образом, его также можно передавать как заголовки с помощью basic-auth.

person Adam Wagner    schedule 01.04.2011
comment
Обратите внимание: 1) это просто сокращение от базовой аутентификации, 2) не все HTTP-клиенты будут его соблюдать, и 3) по крайней мере один из основных браузеров покажет предупреждение о фишинге. - person user359996; 11.09.2012
comment
@ user359996 Очки взяты. В ответ: 1) Я уклонился от этого в своем последнем предложении, 2) Это упоминается в стандартных (инструментах .ietf.org / html / rfc3986), так что это вина клиента, 3) я не знал об этом, хотя я полагаю, что это имеет смысл, интересно, так ли это до сих пор при использовании в качестве API-вызов (XHR). Наконец, вопрос был о включении auth-info в URL-адрес в спокойной форме, и я думаю, что ответил на это. - person Adam Wagner; 12.09.2012

arrow_upward
1
arrow_downward

передача ключа api в параметрах затрудняет для клиентов сохранение своих ключей API в секрете, они имеют тенденцию к утечке ключей на регулярной основе. Лучше передать его в заголовке URL-адреса запроса. Вы можете установить заголовок пользовательского ключа в своем коде. Для тестирования URL-адреса вашего запроса вы можете использовать приложение Postman в Google Chrome, установив заголовок пользовательского ключа для своего API-ключа.

person himanshu_chawla    schedule 15.07.2017
comment
Как ключи api в параметрах вызывают утечку ключей у пользователей? - person Heinzlmaen; 05.07.2019