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

Question

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

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

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

Answer 1

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

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

или все три?

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

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

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

Answer 2

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

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

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

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

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

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

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