Oauthlib: Недопустимые статусы HTTP при ответе об ошибке

В спецификации упоминается, что 401 может использоваться с недопустимыми ошибками клиента и должен использоваться, когда аутентификация была выполнена через поле заголовка авторизации. Хотя в настоящее время oauthlib ничего не делает, чтобы предположить, что поле заголовка «WWW-Authenticate» должно быть включено в ответ, как того требует спецификация. Я считаю, что оставить 401 для этой ошибки нормально, но мы должны добавить предложение заголовка к исключению.

Что касается другого, в спецификации прямо не говорится, что может использоваться 401, и поэтому нам, вероятно, следует подумать о переходе на 400. Однако это кажется более подходящим с 401 как в случае недопустимого гранта, так и особенно в случае ошибок неавторизованного клиента.

@asteinlein , @lepture , @masci мысли?

@ib-lundgren Привет - только что наткнулся на эту самую проблему и хотел бы присоединиться. Прочитав спецификацию и просмотрев другие ответы, IMO 400 - правильный ответ.

Во-первых, спецификация:

Сервер авторизации отвечает HTTP 400 (неверный запрос).
код состояния (если не указано иное) и включает в себя следующие
параметры с ответом:

В требованиях 400 нет ДОЛЖЕН, но нет и МОЖЕТ.

Во-вторых, и причина, по которой я наткнулся на это, заключалась в ошибке своего рода на солнце JDK на моем клиенте (см. здесь: http://stackoverflow.com/a/7524681/1137254)

По сути, HTTP-стек моего клиента рано закроет соединение из-за ошибки 401, но приведенный выше стек OAuth (google-http-oauth-client) попытается продолжить чтение и анализ результатов. Я думаю, что это было написано в OpenJDK в соответствии с определением и ожиданиями вокруг 401 (ОБНОВЛЕНИЕ: на самом деле это связано с «потоковым» режимом). IMO OpenJDK тоже ошибается, и я думаю, что столкнулся бы с той же проблемой, если бы получил «invalid_client» 401 во время запросов конечной точки /token.

Добавление еще одного голоса за 400 является правильным кодом ошибки здесь. Раньше мы использовали django-oauth2-provider для аутентификации oauth2 из мобильных приложений, и в этом случае он возвращал 400. При переходе на django-oauth-toolkit (который использует oauthlib) для обновления до более новых версий Django нам пришлось взломать представление запроса токена, чтобы вместо этого возвращалось 400, чтобы мобильные приложения работали правильно.

Вот один из авторов спецификации, в котором конкретно указано, что 400 является предполагаемым ответом для недействительных учетных данных аутентификации при запросе токена и почему: https://www.ietf.org/mail-archive/web/oauth/current/msg02127 .html

И вот еще один пример проекта, который не справляется с oauthlib, используя 401 в этих обстоятельствах.

+1 за 400

Голосуй за 400

Я возрождаю эту старую тему и начинаю PR с изменениями, предложенными выше.

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

• Рабочая группа OAuth2.0 RFC6749 решила принять 400 для статуса ошибки HTTP вместо 401, поскольку для этого требуется установить WWW-Authenticate , а это не всегда возможно во всех ответах об ошибках.
• @asteinlein предложил PR на https://github.com/oauthlib/oauthlib/pull/247 , чтобы изменить ошибки oauthlib с 400 на 401, потому что _некоторые клиенты, похоже, ожидают 401 для вызовов API, связанных с авторизацией_. Хотя это должно было быть правдой, мы не знаем, какие клиенты были взломаны.
• Несколько всплывающих окон с ошибками в сторонних библиотеках https://github.com/oauthjs/angular-oauth2/issues/31 https://github.com/oauthjs/angular-oauth2/issues/32#issuecomment -88888755 https://github .com/oauthjs/angular-oauth2/issues/36 . Теперь все вопросы закрыты.
• Общий консенсус текущего потока, а также RFC6749#5.2 заключается в том, что все 401 в oauthlib должны быть 400 . Однако у нас есть два случая с 401 :

1. invalid_client , где ДОЛЖНО быть 401 , если используется HTTP-аутентификация, иначе МОЖЕТ быть 401 .
2. invalid_token , где ДОЛЖНО быть 401 .

В любом случае, если используется 401 , ДОЛЖЕН быть установлен WWW-Authenticate ( RFC2616 ).

Другие реализации OAuth2.0

Краткий обзор наиболее распространенных реализаций OAuth2.0 похож на общий консенсус:

• Google возвращает 400 so-question / so-question .
• Salesforce возвращает 400 salesforce-forum .
• Azur возвращает 401 с WWW-Authenticate azur-docs .
• AWS возвращает 400 aws-cognito-docs . Они нарушили « ДОЛЖЕН » RFC, чтобы он составлял 401 при использовании HTTP-аутентификации.

Заключение

Мы должны соответствовать RFC, однако, чтобы не нарушать реализацию, мы не должны включать эти изменения в версию 2.xx, а должны дождаться версии 3.xx.

Пожалуйста, не стесняйтесь вмешиваться.

Я не могу вспомнить причину/клиента(ов), которые заставили меня отправить PR #247, но я вижу и понимаю причины для отмены этого. Спасибо за потрясающее исследование @JonathanHuot , и сделать это в 3.x звучит как лучший подход.

Исправлено в #561/oauthlib>= 3.0.0

в соответствии с этим RFC, упомянутым выше, недопустимый клиент также должен возвращать статус 400, но в пакете все еще есть 401.

Привет @esfandiaryfard , не могли бы вы указать точный текст RFC? Спасибо!