Разработка API: Базовая аутентификация HTTP против токена API

Question

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

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

   Запросы необходимо отправлять на URL

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

2. Передача API-токена в качестве параметра строки запроса.

   Запросы необходимо отправлять на URL-адрес

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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