API Design: HTTP Basic Authentication vs API Token

В настоящее время я создаю систему аутентификации перед публичным веб-API для веб-приложения. Учитывая, что каждая учетная запись пользователя имеет ключ API, и каждый запрос должен быть аутентифицирован, у меня есть две альтернативы:

  • Используя базовую аутентификацию HTTP, как это делает GitHub.

    Запросы должны быть отправлены по URL-адресу

    http://api.example.com/resource/id
with basic authentication
username: token
password: the api key

  • Передача маркера API в качестве параметра querystring.

    Запросы должны быть отправлены по URL-адресу

    http://api.example.com/resource/id?token=api_key

Также есть третий вариант, который передает токен в URI, но мне, честно говоря, не нравится это решение.

Какое решение вы бы приняли и почему?

Ответы

Ответ 1

Я думаю, что HTTP Basic Auth должен быть в порядке, но просто для действительно простых потребностей.

Полное (и окончательное) решение IMHO заключается в реализации поставщика OAuth. Это не сложно, это простой протокол и дает вам большую гибкость. Кроме того, это, как представляется, текущая тенденция, так как многие крупные игроки реализуют ее, и она поддерживается многими библиотеками.

Ответ 2

Лучшая ставка может заключаться в использовании ключа API в заголовке (например, "Авторизация: токен MY_API_KEY" ) вместо параметра URL:

Преимущества по сравнению с HTTP Basic Auth:

  • Более удобно, так как вы можете легко закончить или регенерировать токены, не затрагивая пароль учетной записи пользователя.
  • Если скомпрометировано, уязвимость, ограниченная API, а не главная пользовательская учетная запись
  • У вас может быть несколько ключей для каждой учетной записи (например, пользователи могут иметь "тестовые" и "производственные" стороны рядом.)

Преимущества по ключу API в URL:

  • Обеспечивает дополнительную меру безопасности, предотвращая непреднамеренное совместное использование пользователями URL-адресов с их учетными данными, встроенными в них. (Кроме того, URL-адрес может завершиться такими вещами, как журналы сервера).

Ответ 3

Много раз мне приходилось думать о том, как аутентифицировать пользователей/запросы на API и после сравнения большего количества решений я закончил с помощью Amazon solution где мне не нужно, или я не могу использовать OAuth. Это решение основано на сигнатурах, которые предотвращают проблемы "человек в середине" в качестве Basic Auth и пропускают простой токен, отправляя текстовые данные. Да, вы можете добавить ssl, но это добавит сложности в систему...

Ответ 4

Я бы предпочел использовать решение токена. Если у вас нет фактических пользователей с их собственным именем пользователя и паролем, то кажется, что вы используете конструкцию Basic Auth не так, как предполагалось. Не то чтобы это было обязательно неправильно, но не так чисто, ИМО. Он также устраняет необходимость использования пользовательских заголовков, и я думаю, что он делает реализацию на обеих сторонах проще и чище. Следующий вопрос, который я хотел бы задать, - это использовать двухфакторную аутентификацию или вообще управлять сеансами.