Oauthlib: Statuts HTTP non valides sur la réponse d'erreur

La spécification mentionne que 401 peut être utilisé avec des erreurs client invalides et doit être utilisé lorsque l'authentification a été effectuée via le champ d'en-tête d'autorisation. Bien que oauthlib ne fasse actuellement rien pour suggérer que le champ d'en-tête 'WWW-Authenticate' devrait être inclus dans la réponse comme l'exige la spécification. Je pense que garder 401 pour cette erreur est correct mais nous devrions ajouter une suggestion d'en-tête à l'exception.

En ce qui concerne l'autre, la spécification ne dit pas explicitement que 401 peut être utilisé et nous devrions donc probablement envisager de passer à 400. Cependant, cela semble plus approprié avec un 401 à la fois pour les attributions non valides et en particulier pour les erreurs client non autorisées.

@asteinlein , @lepture , @masci pensées ?

@ib-lundgren Salut - je viens de tomber sur ce problème et j'aimerais intervenir. En lisant les spécifications et en regardant autour d'autres réponses, IMO a 400 est la bonne réponse.

Tout d'abord, la spécification :

Le serveur d'autorisation répond par un HTTP 400 (Bad Request)
code d'état (sauf indication contraire) et comprend les éléments suivants
paramètres avec la réponse :

Il n'y a pas de MUST dans les 400 exigences, mais il n'y a pas non plus de MAY.

Deuxièmement, et la raison pour laquelle je suis tombé là-dedans était une sorte de bogue dans le soleil JDK sur mon client (voir ici : http://stackoverflow.com/a/7524681/1137254 )

Essentiellement, la pile HTTP de mon client fermerait la connexion plus tôt pour un 401, mais la pile OAuth ci-dessus (google-http-oauth-client) tenterait de continuer à lire et à analyser les résultats. Je pense que cela a été écrit dans OpenJDK selon la définition et les attentes autour d'un 401 (MISE À JOUR : c'est en fait lié au mode 'streaming'). IMO OpenJDK a également tort et je pense que je rencontrerais le même problème si j'obtenais un "invalid_client" 401 lors des demandes de point de terminaison /token.

Ajouter un autre vote pour 400 étant le code d'erreur correct ici. Nous avions l'habitude d'utiliser django-oauth2-provider pour l'authentification oauth2 à partir d'applications mobiles, et il renvoyait 400 dans ce cas. Lors du passage à django-oauth-toolkit (qui utilise oauthlib) afin de passer aux nouvelles versions de Django, nous avons dû pirater la vue de demande de jeton pour renvoyer un 400 à la place afin que les applications mobiles fonctionnent correctement.

Voici l'un des auteurs de la spécification indiquant spécifiquement qu'un 400 est la réponse prévue pour les identifiants d'authentification non valides lors de la demande d'un jeton, et pourquoi : https://www.ietf.org/mail-archive/web/oauth/current/msg02127 .html

Et voici un autre exemple de projet qui a du mal à faire face à oauthlib en utilisant un 401 dans ces circonstances.

+1 pour 400

Votez pour 400

Je relance ce vieux fil et lance un PR avec les changements suggérés ci-dessus.

Avant d'avancer sur ce sujet, j'aimerais résumer les discussions qui ont eu lieu dans le passé.

• Le groupe de travail OAuth2.0 RFC6749 a décidé d'adopter 400 pour le statut HTTP d'erreur au lieu de 401, car il nécessite que WWW-Authenticate soit défini, et ce n'est pas toujours possible dans toutes les réponses d'erreur.
• @asteinlein a proposé un PR à https://github.com/oauthlib/oauthlib/pull/247 pour changer les erreurs d'oauthlib de 400 à 401, car _certains clients semblent s'attendre à 401 pour les appels d'API liés à l'autorisation_. Alors que cela devait être vrai, nous ne savons pas quels clients ont été brisés.
• Plusieurs bugs apparaissent dans les librairies tierces 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 . Les problèmes sont tous fermés maintenant.
• Le consensus général du thread actuel, ainsi que de la RFC6749#5.2 , est que tous les 401 dans oauthlib doivent être 400 . Cependant, nous avons deux cas avec 401 :

1. invalid_client , où il DOIT être 401 si l'authentification HTTP est utilisée, sinon il PEUT être 401 .
2. invalid_token , où il DEVRAIT être 401 .

Dans tous les cas, si 401 est utilisé, WWW-Authenticate DOIT être défini ( RFC2616 ).

Autres implémentations OAuth2.0

Un aperçu rapide des implémentations OAuth2.0 les plus courantes est similaire au consensus général :

• Google renvoie 400 telle-question / telle-question .
• Salesforce renvoie 400 salesforce-forum .
• Azur renvoie 401 avec WWW-Authenticate azur-docs .
• AWS renvoie 400 aws-cognito-docs . Ils ont cassé le " MUST " de la RFC pour être 401 lorsque l'authentification HTTP est utilisée.

conclusion

Nous devons nous aligner sur la RFC, cependant pour ne casser aucune implémentation, nous ne devons pas inclure ces changements dans la version 2.xx, mais attendre la 3.xx

S'il vous plaît, n'hésitez pas à intervenir.

Je ne me souviens pas de la raison/du ou des clients qui m'ont poussé à pousser le PR #247, mais je vois et je comprends les raisons de revenir sur cette décision. Merci pour la recherche impressionnante @JonathanHuot , et faire cela en 3.x semble être la meilleure approche.

Corrigé dans #561 / oauthlib>= 3.0.0

selon cette RFC mentionnée ci-dessus, le client non valide devrait également renvoyer le statut 400, mais le package est toujours 401

Salut @esfandiaryfard , pourriez-vous pointer le texte exact du RFC ? Merci!