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

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

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

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

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

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

или все три?

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

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

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

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

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

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

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

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

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

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