Oauthlib: Ungültiger HTTP-Status bei Fehlerantwort

Die Spezifikation erwähnt, dass 401 mit ungültigen Client-Fehlern verwendet werden kann und verwendet werden muss, wenn die Authentifizierung über das Autorisierungs-Header-Feld erfolgt ist. Obwohl oauthlib derzeit nicht darauf hindeutet, dass das Header-Feld „WWW-Authenticate“ in die Antwort aufgenommen werden sollte, wie es die Spezifikation erfordert. Ich denke, dass es in Ordnung ist, 401 für diesen Fehler zu behalten, aber wir sollten der Ausnahme einen Header-Vorschlag hinzufügen.

Bezüglich der anderen besagt die Spezifikation nicht ausdrücklich, dass 401 verwendet werden darf, und daher sollten wir wahrscheinlich in Betracht ziehen, zu 400 zu wechseln. Es scheint jedoch angemessener zu sein, mit einem 401 sowohl bei ungültiger Gewährung als auch insbesondere bei nicht autorisierten Client-Fehlern.

@asteinlein , @lepture , @masci Gedanken?

@ib-lundgren Hallo - bin gerade auf genau dieses Problem gestoßen und möchte mich einschalten. Wenn Sie die Spezifikation lesen und sich nach anderen Antworten umsehen, ist IMO ein 400 die richtige Antwort.

Erstmal die Spezifikation:

Der Autorisierungsserver antwortet mit einem HTTP 400 (Bad Request)
Statuscode (sofern nicht anders angegeben) und umfasst Folgendes
Parameter mit der Antwort:

Bei den 400 Anforderungen gibt es kein MUSS, aber auch kein DÜRFEN.

Zweitens, und der Grund, warum ich darauf gestoßen bin, war eine Art Fehler im Sun-JDK auf meinem Client (siehe hier: http://stackoverflow.com/a/7524681/1137254 )

Im Wesentlichen würde der HTTP-Stack meines Clients die Verbindung für einen 401-Fehler vorzeitig schließen, aber der obige OAuth-Stack (google-http-oauth-client) würde versuchen, das Lesen fortzusetzen und die Ergebnisse zu analysieren. Ich denke, dies wurde gemäß der Definition und den Erwartungen um einen 401 in OpenJDK geschrieben (UPDATE: Es hat tatsächlich mit dem „Streaming“ -Modus zu tun). IMO OpenJDK ist auch falsch und ich denke, ich würde auf dasselbe Problem stoßen, wenn ich während /token-Endpunktanforderungen einen „invalid_client“ 401 erhalten würde.

Fügen Sie hier eine weitere Stimme hinzu, damit 400 der richtige Fehlercode ist. Früher haben wir django-oauth2-provider für die oauth2-Authentifizierung von mobilen Apps verwendet und in diesem Fall 400 zurückgegeben. Beim Wechsel zu django-oauth-toolkit (das oauthlib verwendet), um auf neuere Django-Versionen zu aktualisieren, mussten wir die Token-Anforderungsansicht hacken, um stattdessen 400 zurückzugeben, damit die mobilen Apps ordnungsgemäß funktionieren.

Hier ist einer der Autoren der Spezifikation, der ausdrücklich erklärt, dass eine 400 die beabsichtigte Antwort für ungültige Authentifizierungsdaten ist, wenn ein Token angefordert wird, und warum: https://www.ietf.org/mail-archive/web/oauth/current/msg02127 .html

Und hier ist ein weiteres Beispiel für ein Projekt, das unter diesen Umständen Probleme hat, mit oauthlib unter Verwendung eines 401 zurechtzukommen.

+1 für 400

Stimmen Sie für 400

Ich belebe diesen alten Thread wieder und starte eine PR mit den oben vorgeschlagenen Änderungen.

Bevor ich hier weiterkomme, möchte ich die Diskussion zusammenfassen, die in der Vergangenheit stattgefunden hat.

• Die OAuth2.0-RFC6749-Arbeitsgruppe hat beschlossen, 400 für den Fehler-HTTP-Status anstelle von 401 anzunehmen, da dafür WWW-Authenticate festgelegt werden muss und dies nicht immer bei allen Fehlerantworten möglich ist.
• @asteinlein schlug einen PR unter https://github.com/oauthlib/oauthlib/pull/247 vor, um die Fehler von oauthlib von 400 auf 401 zu ändern, da _einige Clients 401 für API-Aufrufe im Zusammenhang mit der Autorisierung zu erwarten scheinen_. Obwohl es wahr sein musste, wissen wir nicht, welche Clients defekt waren.
• Mehrere Fehler erscheinen in Bibliotheken von Drittanbietern 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 . Die Probleme sind jetzt alle geschlossen.
• Der allgemeine Konsens des aktuellen Threads und auch von RFC6749#5.2 ist, dass alle 401 in oauthlib 400 sein müssen. Wir haben jedoch zwei Fälle mit 401 :

1. invalid_client , wobei es 401 sein MUSS , wenn HTTP-Authentifizierung verwendet wird, andernfalls KÖNNTE es 401 sein.
2. invalid_token , wo es 401 sein SOLLTE .

Wenn 401 verwendet wird, MUSS auf jeden Fall WWW-Authenticate gesetzt werden ( RFC2616 ).

Andere OAuth2.0-Implementierungen

Ein kurzer Überblick über die gängigsten OAuth2.0-Implementierungen ähneln dem allgemeinen Konsens:

• Google gibt 400 so-Frage / so-Frage zurück.
• Salesforce gibt 400 salesforce-forum zurück.
• Azur gibt 401 mit WWW-Authenticate azur-docs zurück.
• AWS gibt 400 aws-cognito-docs zurück . Sie brachen das „ MUSS “ des RFC, 401 zu sein, wenn HTTP-Authentifizierung verwendet wird.

Schlussfolgerung

Wir müssen uns an den RFC anpassen, aber um keine Implementierungen zu beschädigen, dürfen wir diese Änderungen nicht in Version 2.xx aufnehmen, sondern bis Version 3.xx warten

Bitte melden Sie sich gerne an.

Ich kann mich nicht an den Grund/die Kunden erinnern, die mich veranlasst haben, PR Nr. 247 zu pushen, aber ich sehe und verstehe die Gründe dafür, dies rückgängig zu machen. Vielen Dank für die großartige Recherche @JonathanHuot , und dies in 3.x zu tun, klingt nach dem besten Ansatz.

Behoben in #561 / oauthlib>= 3.0.0

Laut diesem RFC sollte der oben erwähnte ungültige Client auch den Status 400 zurückgeben, aber im Paket ist immer noch 401

Hallo @esfandiaryfard , könntest du den genauen Text des RFC zeigen? Danke!