Oauthlib: Estados HTTP no válidos en respuesta de error

La especificación menciona que 401 puede usarse con errores de cliente no válidos y debe usarse cuando la autenticación se realizó a través del campo de encabezado de autorización. Aunque oauthlib actualmente no hace nada para sugerir que el campo de encabezado 'WWW-Authenticate' debe incluirse en la respuesta como lo requieren las especificaciones. Considero que mantener 401 para este error está bien, pero deberíamos agregar una sugerencia de encabezado a la excepción.

Con respecto al otro, la especificación no dice explícitamente que se puede usar 401 y, por lo tanto, probablemente deberíamos considerar cambiar a 400. Sin embargo, parece más apropiado con un 401 tanto en la concesión no válida como en los errores de clientes especialmente no autorizados.

@asteinlein , @lepture , @masci pensamientos?

@ib-lundgren Hola: me topé con este mismo problema y me gustaría participar. Al leer las especificaciones y buscar otras respuestas, IMO a 400 es la respuesta correcta.

En primer lugar, la especificación:

El servidor de autorización responde con un HTTP 400 (Solicitud incorrecta)
código de estado (a menos que se especifique lo contrario) e incluye lo siguiente
parámetros con la respuesta:

No hay OBLIGACIÓN en los requisitos 400, pero tampoco MAYO.

En segundo lugar, y la razón por la que tropecé con esto fue a través de una especie de error en el JDK de Sun en mi cliente (ver aquí: http://stackoverflow.com/a/7524681/1137254)

Esencialmente, la pila HTTP de mi cliente cerraría la conexión temprano para un 401, pero la pila OAuth anterior (google-http-oauth-client) intentaría continuar leyendo y analizando los resultados. Creo que esto se escribió en OpenJDK según la definición y las expectativas en torno a un 401 (ACTUALIZACIÓN: en realidad tiene que ver con el modo de 'transmisión'). En mi opinión, OpenJDK también está mal y creo que me encontraría con este mismo problema si obtuviera un "cliente_inválido" 401 durante las solicitudes de punto final/token.

Agregar otro voto para que 400 sea el código de error correcto aquí. Solíamos usar django-oauth2-provider para la autenticación oauth2 desde aplicaciones móviles y devolvió 400 en este caso. Al cambiar a django-oauth-toolkit (que usa oauthlib) para actualizar a versiones más nuevas de Django, tuvimos que piratear la vista de solicitud de token para devolver un 400 y mantener las aplicaciones móviles funcionando correctamente.

Aquí está uno de los autores de la especificación que indica específicamente que un 400 es la respuesta prevista para las credenciales de autenticación no válidas al solicitar un token, y por qué: https://www.ietf.org/mail-archive/web/oauth/current/msg02127 .html

Y aquí hay otro ejemplo de un proyecto que tiene problemas para lidiar con oauthlib usando un 401 en estas circunstancias.

+1 por 400

vota por 400

Estoy reviviendo este viejo hilo y comienzo un PR con los cambios sugeridos anteriormente.

Antes de avanzar en esto, me gustaría resumir la discusión que sucedió en el pasado.

• El grupo de trabajo OAuth2.0 RFC6749 decidió adoptar 400 para el estado HTTP de error en lugar de 401, porque requiere que se configure WWW-Authenticate , y no siempre es posible en todas las respuestas de error.
• @asteinlein propuso un PR en https://github.com/oauthlib/oauthlib/pull/247 para cambiar los errores de oauthlib de 400 a 401, porque _algunos clientes parecen esperar 401 para las llamadas API relacionadas con la autorización_. Si bien tenía que ser cierto, no sabemos qué clientes se rompieron.
• Aparecen varios errores en bibliotecas de terceros 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 . Los problemas están todos cerrados ahora.
• El consenso general del subproceso actual, y también de RFC6749#5.2 , es que todos los 401 en oauthlib deben ser 400 . Sin embargo, tenemos dos casos con 401 :

1. invalid_client , donde DEBE ser 401 si se usa autenticación HTTP, de lo contrario PUEDE ser 401 .
2. invalid_token , donde DEBE ser 401 .

En cualquier caso, si se usa 401 WWW-Authenticate DEBE configurarse WWW-Authenticate ( RFC2616 ).

Otras implementaciones de OAuth2.0

Una descripción general rápida de las implementaciones de OAuth2.0 más comunes es similar al consenso general:

• Google devuelve 400 así que pregunta / así que pregunta .
• Salesforce devuelve 400 foro-salesforce .
• Azur devuelve 401 con WWW-Authenticate azur-docs .
• AWS devuelve 400 aws-cognito-docs . Rompieron el " DEBE " del RFC para ser 401 cuando se utiliza la autenticación HTTP.

conclusión

Tenemos que alinearnos con el RFC, sin embargo, para no romper ninguna implementación, no debemos incluir estos cambios en la versión 2.xx, sino esperar hasta la 3.xx.

Por favor, siéntase libre de intervenir.

No puedo recordar la razón/los clientes que me hicieron empujar PR #247, pero veo y entiendo las razones para revertir esto. Gracias por la increíble investigación @JonathanHuot , y hacer esto en 3.x parece el mejor enfoque.

Corregido en #561 / oauthlib>= 3.0.0

de acuerdo con este RFC que se mencionó anteriormente, el cliente no válido también debería devolver el estado 400 pero en el paquete todavía es 401

Hola @esfandiaryfard , ¿podrías señalar el texto exacto del RFC? ¡Gracias!