Ключи API против HTTP-аутентификации против OAuth в RESTful API


102

Я работаю над созданием RESTful API для одного из поддерживаемых мной приложений. В настоящее время мы планируем встроить в него различные вещи, которые требуют более контролируемого доступа и безопасности. Исследуя, как обеспечить безопасность API, я обнаружил несколько разных мнений о том, какую форму использовать. Я видел, как некоторые ресурсы говорят, что HTTP-Auth - это лучший способ, в то время как другие предпочитают ключи API, и даже другие (включая вопросы, которые я нашел здесь, на SO), придерживаются OAuth.

Затем, конечно, те, кто предпочитает, скажем, ключи API, говорят, что OAuth предназначен для приложений, получающих доступ от имени пользователя (как я понимаю, таких как вход на сайт, не принадлежащий Facebook, с использованием вашей учетной записи Facebook), и не для пользователя, напрямую обращающегося к ресурсам на сайте, на который он специально подписался (например, официальный клиент Twitter, имеющий доступ к серверам Twitter). Однако рекомендации для OAuth подходят даже для самых простых задач аутентификации.

Тогда мой вопрос: если все это делается по HTTPS, каковы некоторые практические различия между этими тремя? Когда одно следует рассматривать выше других?


с чем вы закончили?
Irwin

@Irwin - Я задал этот вопрос некоторое время назад и с тех пор ушел от проекта, требующего этого, но в итоге я использовал комбинацию ключей API и сгенерированный пароль (который пользователи никогда не видят), которые отправляются с использованием HTTP-аутентификации.
Shauna

Ответы:


67

Это зависит от ваших потребностей. Тебе нужно:

  • Идентификация - кто утверждает, что делает запрос API?
  • Аутентификация - действительно ли они те, о которых говорят?
  • Авторизация - разрешено ли им делать то, что они пытаются сделать?

или все три?

Если вам просто нужно идентифицировать вызывающего, чтобы отслеживать объем или количество вызовов API, используйте простой ключ API. Имейте в виду, что если пользователь, которому вы предоставили ключ API, поделится им с кем-то еще, он также сможет вызывать ваш API.

Но если вам также нужна авторизация, то есть вам нужно предоставить доступ только к определенным ресурсам на основе вызывающего API, а затем используйте oAuth.

Вот хорошее описание: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/


с "определенными ресурсами" вы имеете в виду "определенные вызовы API" или "определенные записи базы данных", или и то, и другое?
Magne

В основном записи БД (или все, что обнаруживает защищенное состояние или изменяет состояние). Но это также может быть что-то вроде премиальной функции (например, запуск алгоритма в облаке), которая на самом деле ничего не меняет в базе данных, но использует системные ресурсы и должна быть доступна только авторизованным лицам.
Сид,

@Sid Я работаю над приложением, которое использует OAuth для регистрации пользователей, которые регистрируются в Facebook или LinkedIn. Кроме того, мы открываем наш API для других сервисов для управления данными. В этом случае вы бы порекомендовали OAuth для аутентификации пользователя и ключ API или комбинацию имени пользователя и пароля (как в статье, на которую вы ссылаетесь) для служб, обращающихся к API? OAuth и ключ api используются для разных целей, верно?
Tom Doe

@TomDoe Привет, Том - Да, в этом есть смысл. Вероятно, вы захотите использовать OAuth2 сейчас. Если ваш сервер находится на Python (Django или Flask), взгляните на github.com/omab/python-social-auth
Сид,

Я не понимаю, как ключ API не может обеспечить эти три вещи. И идентификация, и аутентификация основаны на том, что «знаете ли вы конкретный секрет?» (если вы не введете 2FA, это отдельная тема). Если я дам очень длинный ключ API пользователя 5, это будет утверждать и доказывать, что я пользователь 5, по крайней мере так же хорошо, как имя пользователя / пароль. И нет причин, по которым нельзя было бы назначать разные разрешения для разных ключей API. Правильно? Что мне здесь не хватает?
Натан Лонг,

3

Ключи API или даже токены относятся к категории механизмов прямой аутентификации и авторизации, поскольку они предоставляют доступ к открытым ресурсам REST API. Такие прямые механизмы можно использовать в случаях использования делегирования.

Чтобы получить доступ к ресурсу или набору ресурсов, предоставляемых конечными точками REST, необходимо проверить права инициатора запроса в соответствии с его идентификатором. Затем первым шагом рабочего процесса является проверка личности путем аутентификации запроса; последующий шаг - проверка идентичности по набору определенных правил для авторизации уровня доступа (то есть чтение, запись или чтение / запись). После того, как указанные шаги выполнены, типичным дополнительным вопросом является допустимая скорость запросов , означающая, сколько запросов в секунду запрашивающей стороне разрешено выполнять по отношению к данному ресурсу (ресурсам).

OAuth (открытая авторизация) - это стандартный протокол для делегированного доступа , часто используемый крупными интернет-компаниями для предоставления доступа без предоставления пароля. Понятно, что OAuth - это протокол, который решает указанные выше проблемы: аутентификация и авторизация, обеспечивая безопасный делегированный доступ к ресурсам сервера от имени владельца ресурса. Он основан на механизме токенов доступа, который позволяет третьей стороне получить доступ к ресурсу, управляемому сервером, от имени владельца ресурса. Например, ServiceX хочет получить доступ к учетной записи Google Джона Смита от имени Джона, как только Джон санкционирует делегирование; Затем ServiceX будет выпущен токен с привязкой по времени для доступа к данным учетной записи Google, скорее всего, только для чтения.

Концепция ключа API очень похожа на токен OAuth, описанный выше. Основное отличие состоит в отсутствии делегирования: Пользователь напрямую запрашивает Ключ у поставщика услуг для последовательных программных взаимодействий. Случай с API-ключом также зависит от времени: ключ в качестве токена OAuth подлежит временной аренде или сроку действия. В качестве дополнительного аспекта, ключ, а также токен могут подлежать ограничению скорости в соответствии с контрактом на обслуживание, то есть может быть обслужено только заданное количество запросов в секунду.

Напомним, что на самом деле нет реальной разницы между традиционными механизмами аутентификации и авторизации и версиями на основе ключей / токенов. Однако парадигма немного отличается: вместо того, чтобы продолжать повторно использовать учетные данные при каждом взаимодействии между клиентом и сервером, используется поддерживающий ключ / токен, который делает общее взаимодействие более плавным и, вероятно, более безопасным (часто, в соответствии со стандартом JWT , ключами и Жетоны имеют цифровую подпись сервера, чтобы избежать крафта).

  • Прямая проверка подлинности и авторизация : протоколы на основе ключей как вариант традиционных версий на основе учетных данных.
  • Делегированная аутентификация и авторизация : например, протоколы на основе OAuth, которые, в свою очередь, используют токены, опять же как вариант версий на основе учетных данных (общая цель - не раскрывать пароль какой-либо третьей стороне).

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.