Почему я должен передавать `client_secret` для получения` access_token`?

Question

Чтобы получить access_token от Facebook, вам необходимо передать app_id, code, которые вы получите после запроса на авторизацию, и secret_key вашего приложения.

Зачем мне КОГДА-ЛИБО передать мой секретный ключ? Это кажется явно небезопасным. Это требование спецификации OAuth 2.0?

Как связанный вопрос, зачем мне передавать app_id, когда мой запрос уже подписан с моим consumer_key?

У меня есть работающее приложение, я просто не понимаю эти требования.

Answer 1

Это требование спецификации OAuth 2.0, раздел 4.1.3 .

Если тип клиента является конфиденциальным или ему были выданы учетные данные клиента (или назначены другие требования для проверки подлинности)), клиент ДОЛЖЕН пройти аутентификацию на сервере авторизации , как описано в разделе 3.2.1

И в разделе 3.2.1 относится к разделу 2.3.В частности, раздел 2.3.1 говорит:

В качестве альтернативы, сервер авторизации МОЖЕТ разрешить включать учетные данные клиента в тело запроса, используя следующие параметры:

client_id

   REQUIRED.  The client identifier issued to the client during
   the registration process described by Section 2.2.

client_secret

   REQUIRED.  The client secret.  The client MAY omit the
   parameter if the client secret is an empty string.

Есть и другие способы, которые предлагает OAuth 2.0, но, выбрав этот подход, Facebookхорошо в пределах спецификации.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *. Теперь, когда Фейсбук выбрал этот подход, может ответить только Фейсбук.

Answer 2

Помимо того, что это требование Oauth2, client_secret необходимо использовать на этом этапе, чтобы убедиться, что вы действительно являетесь тем, на кого вы претендуете.

Все сводится к тому, почему процесс такой, какой он есть ...

«Код», который вы получаете по первому запросу, довольно слабый с точки зрения безопасности сам по себе. Он может быть перехвачен на обратном пути по ссылке перенаправления, которую я часто видел, переходя на целевые страницы без защиты SSL. Даже если вы на 100% HTTPS на своем сайте, все не совсем безопасно. Кто-то может найти код по просмотру URL-адресов запросов, которые регистрируются в журналах доступа вашего веб-сервера.

Даже если у вас есть самая жесткая среда безопасности на этой стороне Букингемского дворца, контролирующая доступ к вашим серверам, если вы работали на техническом родео более нескольких лет, вы знаете, что кто-то собирается в какой-то момент «заархивировать» ваш журналы где-то менее чем идеально в безопасности. Вероятно, на USB-ключе они оставили в Starbucks ...

Ничего не может быть, не избегайте этого, если вы используете поток API на стороне сервера. В отличие от Javascript, работающего внутри клиентского браузера, вы не можете добавить временный код после хеша, чтобы предотвратить его регистрацию, потому что клиенты браузера не отправляют что-либо после хеш-метки с запросом. JS может перехватить URL-адрес перенаправления и проанализировать содержимое после тега Hash, поэтому существует поток JS Oauth2, который просто возвращает access_token без дополнительного промежуточного кода песни и танца. Нет необходимости в Client_Secret на стороне JS, и это хорошо, так как это обычно вызывает недовольство, когда вы помещаете пароли и секретные ключи в javascript.

Теперь, чтобы предотвратить использование этого промежуточного кода злоумышленником для получения токена доступа, Client_ID и Client_Secret отправляются вместе, чтобы сервер API мог идентифицировать вас как того, кем вы себя называете, и у вас есть разрешение выкупить код для access_token. Ничто не сравнится с общим секретом!

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

Сочетание короткого окна использования и client_secret (более ssl, конечно) обеспечивает обмен данными с вашими учетными данными клиента

Answer 3

Обратите внимание на слова .... НЕ РЕКОМЕНДУЕТСЯ.

2.3.1.Пароль клиента

Клиенты, владеющие паролем клиента, МОГУТ использовать базовую схему аутентификации HTTP, как определено в [RFC2617], для аутентификации на сервере авторизации.Идентификатор клиента кодируется с использованием алгоритма кодирования application / x-www-form-urlencoded в соответствии с Приложением B, и закодированное значение используется в качестве имени пользователя;пароль клиента кодируется с использованием того же алгоритма и используется в качестве пароля.Сервер авторизации ДОЛЖЕН поддерживать базовую схему аутентификации HTTP для аутентификации клиентов, которым был выдан пароль клиента.

Например (с дополнительными разрывами строк только для отображения):

 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

В качестве альтернативы,сервер авторизации МОЖЕТ поддерживать включение учетных данных клиента в тело запроса, используя следующие параметры:

client_id REQUIRED.Идентификатор клиента, выданный клиенту во время процесса регистрации, описанного в разделе 2.2.

client_secret REQUIRED.Секрет клиента.Клиент МОЖЕТ пропустить параметр, если секрет клиента является пустой строкой.

Включение учетных данных клиента в тело запроса с использованием двух параметров НЕ РЕКОМЕНДУЕТСЯ и ДОЛЖНО быть ограничено клиентами, которые не могут напрямую использоватьбазовая схема аутентификации HTTP (или другие схемы аутентификации HTTP на основе пароля). Параметры могут передаваться только в теле запроса и НЕ ДОЛЖНЫ включаться в URI запроса.

Например,запрос на обновление токена доступа (раздел 6) с использованием параметров тела (с дополнительными разрывами строк только для отображения):

 POST /token HTTP/1.1
 Host: server.example.com
 Content-Type: application/x-www-form-urlencoded

 grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
 &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

Сервер авторизации ДОЛЖЕН требовать использования TLS, как описано в разделе 1.6 при отправкезапросы с использованием аутентификации по паролю.

Поскольку этот метод аутентификации клиента включает пароль, сервер авторизации ДОЛЖЕН защищать любую конечную точку, использующую его, от атак методом перебора.