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

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

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

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

Ответ 1

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

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

или все три?

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

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

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

Ответ 2

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

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

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

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

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

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

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