OAuth2 Grant type Client Credentials - разрешен ли метод GET

Question

Я обращаюсь к службе, которая предоставляет токен доступа через метод GET, который принимает client_id и client_secret в качестве параметров строки запроса. Служба утверждает, что это жалоба на OAuth2. Я посмотрел на OAuth2 spe c для предоставления учетных данных клиента. Вот что говорит spe c:

Клиент делает запрос к конечной точке токена, добавляя следующие параметры с использованием "application / x- www-form-urlencoded" формат согласно Приложению B с кодировкой символов UTF-8 в HTTP Тело объекта запроса:

ТРЕБУЕТСЯ тип_предоставления. Значение ДОЛЖНО быть установлено на client_credentials.

scope НЕОБЯЗАТЕЛЬНО. Объем запроса на доступ описан в разделе 3.3.

Клиент ДОЛЖЕН аутентифицироваться на сервере авторизации как описано в Разделе 3.2.1.

Несмотря на то, что он явно не исключает метод GET, spe c разрешает только POST для предоставления токена доступа. Правильно ли сказать, что OAuth2 spe c не разрешает метод GET для получения токена доступа для предоставления учетных данных клиента?

Answer 1

Передача идентификатора клиента и / или секретного кода клиента в качестве строки запроса является плохой реализацией инфраструктуры OAuth 2.0. Независимо от того, использует ли API метод GET или POST. Я совсем недавно видел другой API (Datanas), который использовал метод POST, но требовал передать идентификатор клиента и секрет клиента в строке запроса. Здесь сообщалось о проблеме .

RF C 6749 определяет, как получить токен доступа при использовании OAuth2. Упрощенно:

• идентификатор клиента + секрет клиента ДОЛЖНЫ передаваться в заголовке авторизации (с использованием basi c auth)
• , а код ДОЛЖЕН передаваться в теле .
• клиент ДОЛЖЕН использовать метод HTTP POST при запросах токенов доступа.

Лучшее, что вы можете сделать, - это связаться со службой поддержки API и спросить они свяжут вас со своей командой инженеров.

Answer 2

Похоже на неправильную реализацию - спецификации OAuth никогда не рекомендуют этого, поскольку:

• Учетные данные обычно записываются в журналы веб-сервера, что плохо
• Запросы GET могут быть кэшируется в различных местах конвейера HTTP, что приводит к возврату старого токена.

Запросы POST, конечно, не имеют вышеуказанных проблем.