Oauthlib: Client_secret и code_verifier (PKCE) должны передаваться безопасно

Привет @polamayster , ты совершенно прав.

Я добавляю разделы RFC, определяющие, как это должно быть реализовано:

Раздел OAuth2.0 RFC:

https://tools.ietf.org/html/rfc6749#section -2.3.1

2.3.1.  Client Password
   Clients in possession of a client password
   MAY use the HTTP Basic authentication scheme (..) 

   Alternatively, the authorization server
   MAY support including the client credentials in the request-body (..)

   The parameters can only be transmitted in the request-body and
   MUST NOT be included in the request URI.

Раздел PKCE RFC:

https://tools.ietf.org/html/rfc7636#section -4.5

4.5.  Client Sends the Authorization Code and the Code Verifier to the
      Token Endpoint
    In addition to the parameters defined in the OAuth 2.0 Access
    Token Request (Section 4.1.3 of [RFC6749]), it sends the following parameter:

   code_verifier
      REQUIRED.  Code verifier

https://tools.ietf.org/html/rfc6749#section -4.1.3

4.1.3.  Access Token Request

   The client makes a request to the token endpoint by sending the
   following parameters (..) in the HTTP request entity-body:

Так что я не сомневаюсь в актуальности проблемы. Приветствуются любые пиары!

Я буду заинтересован в этом. Скоро отправлю запрос на перенос.

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

Для моего понимания oauthlib.common.Request класса имеет __getattr__ методы и _params словарь (обновляются из строки запроса и параметров тела) и любого запроса , который пытается получить доступ / прибудет client_secret или code_verifier должны искать только в теле и / или заголовках (возможно, имеет смысл иметь отдельное свойство для поиска конфиденциальных данных)

Понятно, я отправлю за это PR сегодня

В сб, 20 апреля 2019 г., 12:38 Богдан < [email protected] написал:

Насколько я понимаю, класс oauthlib.common.Request имеет __getattr__
метод и словарь _params (обновляется из строки запроса и тела
параметры) и любой запрос, который пытается получить доступ / получить client_secret или
code_verifier должен искать только в теле и / или заголовках (возможно, имея
имеет смысл отдельное свойство для поиска конфиденциальных данных)

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/oauthlib/oauthlib/issues/666#issuecomment-485157051 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABKEVQNFJUFGDB5X24JBOJDPRNWKBANCNFSM4HHD7NNQ
.

Для моего понимания oauthlib.common.Request класса имеет __getattr__ методы и _params словарь (обновляются из строки запроса и параметров тела) и любого запроса , который пытается получить доступ / прибудет client_secret или code_verifier должны искать только в теле и / или заголовках (возможно, имеет смысл иметь отдельное свойство для поиска конфиденциальных данных)

Значит, проверки должны происходить во время доступа к атрибуту, а не при установке url? Если атрибуты запроса устанавливаются только один раз при инициализации, мы можем выполнять проверки прямо тогда, а не при каждом доступе к атрибуту. Дайте мне знать, если вы считаете, что мы все еще должны выполнять проверки при каждом доступе к атрибуту.

Я понимаю, что эта проблема серьезнее и касается всей конечной точки /token . Эта конечная точка НЕ ​​ДОЛЖНА принимать никаких параметров в URL-адресе. Это НЕ ДОЛЖНО быть разрешено.

Я думаю, что конечная точка самоанализа тоже подходит. IIRC, согласно
Спецификации HTTP, запросы POST всегда должны игнорировать параметры запроса. Если
мы обеспечиваем это, мы автоматически решаем все проблемы, не затрагивая
допустимые варианты использования. Я не уверен, как должны себя вести другие HTTP-глаголы
но я почти уверен в POST one. Может ли кто-нибудь подтвердить, правильно ли это
направление идти навстречу?

>

Отказ от всех параметров запроса для всех POST - это хороший и привлекательный ярлык! Однако меня беспокоит ResourceEndpoint oauthlib и тот факт, что некоторые пользователи все еще могут добавлять аргументы запроса в URL-адрес (несмотря на то, что это не рекомендуется, это все еще возможно технически).

Не могли бы вы подробнее рассказать о своих проблемах с конечной точкой ресурса?

Насколько я понимаю, запросы POST выполняются либо через отправку формы, либо через api
вызовы (написание явного кода). Я не понимаю, зачем кому-то добавлять частичные
данные как параметры запроса и частичные как данные публикации. На самом деле легче
полностью придерживаться любого из них.
На самом деле, если вы используете библиотеку для выполнения запросов, гораздо проще
добавить все как тело сообщения вместо того, чтобы разделять его.

Пользователи, добавляющие параметры запроса в POST, если отображаются с пояснительной ошибкой,
должен уметь быстро исправлять ошибки.

Или, может быть, мы можем создать миксин или декоратор, который при применении поднимет
ошибки для запросов POST с параметрами запроса.

Вот еще одно возможное решение. Для конечных точек ( AuthorizationEndpoint , IntrospectEndpoint , RevocationEndpoint ); Если метод запроса - POST мы можем добавить проверку параметров запроса в соответствующие методы проверки запроса. Для ( TokenEndpoint , MetadataEndpoint ) мы можем добавить проверку в методы генерации ответа.
ИЛИ мы можем добавить механизм проверки в метод генерации ответов для всех из них для единообразия. Звучит как хорошая идея?

Я думаю, что предпочтительнее использовать методы проверки _request_.
Зная, что POST используется только для TokenEndpoint , IntrospectEndpoint и RevocationEndpoint . Другие: GET : AuthorizationEndpoint , MetadataEndpoint .

Однако общий комментарий: следует ли нам сосредоточиться на конфиденциальных полях (например, поддерживать черный список) или нам следует запретить все параметры OAuth2 (мы хотим, чтобы NONE было в URI запроса, верно?)

В идеале я бы хотел NONE в URI запроса. Я попал в черный список, потому что я не был
конечно, если я могу нарушить некоторые существующие варианты использования. Мало того, что нет OAuth2
параметры разрешены, но параметры запроса не допускаются.

>

Если вы переместите проверки из запроса в конечные точки, я не вижу никаких проблем с отключением всех параметров запроса для этих конечных точек!

Хорошо, тогда я отключу все параметры запроса на этих точных конечных точках. И
мы также ограничиваем HTTP-метод POST, верно?

Исправлено в https://github.com/oauthlib/oauthlib/pull/667

Хотя я понимаю причину этого изменения, это кажется критическим изменением для клиентов, которые отправляют client_secret в качестве параметра запроса. Я ожидал обратной совместимости или резкого увеличения версии. Это поведение задумано?

В настоящее время мы используем django-oauth-toolkit, и клиенты отправляют username , password , client_secret , client_id и grant_type качестве запроса. параметр. Если они переключаются на отправку всего как параметра POST , они получают ошибку unsupported_grant_type .

Поддержка запроса POST - это скорее побочный эффект, чем желаемое поведение. Я понимаю, что это сломает вашего клиента, поэтому я предлагаю указать на <3.1
Кроме того, рассмотрите возможность обновления как можно скорее, поскольку это связано с проблемами безопасности (секреты отображаются в журналах, в прокси-сервере в нескольких непредусмотренных местах).