¿Qué código HTTP debo usar para una falla de autenticación de terceros?

Estoy creando una aplicación que tiene integraciones con aplicaciones de terceros.

Para hacer esto, el usuario conectado envía una clave API para la integración de terceros.

En el caso de que la clave API que enviaron no sea válida (y devuelva un 401 del tercero), ¿qué respuesta HTTP debo devolver?

Devolver un 401 de mi aplicación suena confuso porque desde el punto de vista de la interfaz, no está claro si mi aplicación o la aplicación de terceros no están autenticadas.

Estoy tentado de darle un 400, como si hubieran enviado un formulario con una dirección de correo electrónico no válida, etc.

Si tuviera que elegir un código, probablemente elegiría devolver 403 Prohibido.

RFC 7231 §6.5.3 describe el código 403 de la siguiente manera:

El código de estado 403 (Prohibido) indica que el servidor entendió la solicitud pero se niega a autorizarla. Un servidor que desea hacer público por qué se ha prohibido la solicitud puede describir esa razón en la carga útil de respuesta (si la hay).

Si se proporcionaron credenciales de autenticación en la solicitud, el servidor las considera insuficientes para otorgar acceso. El cliente NO DEBE repetir automáticamente la solicitud con las mismas credenciales. El cliente PUEDE repetir la solicitud con credenciales nuevas o diferentes. Sin embargo, una solicitud puede estar prohibida por razones ajenas a las credenciales.

Un servidor de origen que desea "ocultar" la existencia actual de un recurso objetivo prohibido PUEDE responder en su lugar con un código de estado de 404 (No encontrado).

Este código de estado se usa comúnmente como una respuesta genérica de 'error de autenticación' y no es probable que active ningún mecanismo de autenticación específico, como 401 puede obligar a un navegador a mostrar un mensaje de nombre de usuario / contraseña. La razón específica por la cual la autenticación falló se puede describir en el cuerpo de la respuesta, ya sea en forma legible por máquina (por ejemplo, JSON o XML), o como un documento legible por humanos (por ejemplo, HTML).

El código 400 no es la peor opción posible aquí, pero es bastante genérico.

Puede usar el código de estado Código de estado HTTP - 407 (se requiere autenticación de proxy). De la referencia de desarrolladores de Mozilla :

El código de respuesta de estado de error del cliente HTTP 407 requiere autenticación proxy indica que la solicitud no se ha aplicado porque carece de credenciales de autenticación válidas para un servidor proxy que se encuentra entre el navegador y el servidor que puede acceder al recurso solicitado.

Su aplicación de back-end está actuando como un proxy para API de terceros, por lo que está bien usar 407 en este caso.

407no es correcto. En este caso, su código es el proxy y está autenticado. Es un sistema extraño que no está autenticado.

401es razonable pero es engañoso acerca de lo que no está autenticado ya que el cliente está autenticado en su sistema. Esto tampoco funciona si su autenticación extranjera se difiere hasta después de 100Continue.

400 no es correcto ya que la solicitud era válida en formato pero la autenticación falló en el agente externo.

Todas las otras 4xxrespuestas se descartan fácilmente por no ser aplicables aquí.

Entonces, eso deja 403Prohibido, que en mi opinión es su única opción real en este caso:

403Prohibido El cliente no tiene derechos de acceso al contenido; es decir, no está autorizado, por lo que el servidor se niega a proporcionar el recurso solicitado. A diferencia de 401, el servidor conoce la identidad del cliente. En este caso, también puede ser adecuado responder con un mensaje de estado que indique la "causa raíz" de la falla. Realmente depende de la disposición de seguridad de su aplicación.

Mi $ .02

Yo iría con 400, cumple con el requisito semántico. El usuario proporcionó algunos datos incorrectos. Como usted dice, un 401/403 implica un problema entre el usuario y su sitio, no su sitio y alguna otra aplicación.

La Sección 1 de los estados HTTP 1.1 RFC :

Introducción

Cada mensaje del Protocolo de transferencia de hipertexto (HTTP) es una solicitud o una respuesta. Un servidor escucha en una conexión una solicitud, analiza cada mensaje recibido, interpreta la semántica del mensaje en relación con el objetivo de solicitud identificado y responde a esa solicitud con uno o más mensajes de respuesta. Un cliente construye mensajes de solicitud para comunicar intenciones específicas, examina las respuestas recibidas para ver si las intenciones se llevaron a cabo y determina cómo interpretar los resultados. Este documento define la semántica de solicitud y respuesta HTTP / 1.1 en términos de la arquitectura definida en [RFC7230].

Ergo, la definición de los códigos de estado se encuentra entre un cliente y un servidor. Para mí eso significa elegir el que tenga el mejor sentido para otras interacciones (servidor a servidor, back-end, etc.).

Todos los otros exóticos ofrecidos aquí solo van a confundir al consumidor del servicio.

Siempre es bueno enviar 403

pero si es necesario, puede agregar información json-

[Serializable]
[DataContract]
class Response
{
    [DataMember]
    public bool IsSuccess { get; set; }
    [DataMember]
    public string Message { get; set; }
    [DataMember]
    public object ResponseData { get; set; }

    public Response(bool status, string message, object data)
    {
        IsSuccess = status;
        Message = message;
        ResponseData = data;
    }
}

Y luego en la respuesta agregue la siguiente información también

 return Json(new Response(false, "Login Failed, The user name or password provided is incorrect.", null));

cuando se realiza una solicitud, puede deshabilitar el botón de inicio de sesión, y solo cuando se realiza una actualización, el botón puede habilitarse: lógica del lado del cliente.

Los 424 - Failed Dependencytrajes bastante bien en este caso.

El código de estado 424 (Dependencia fallida) significa que el método no se pudo realizar en el recurso porque la acción solicitada dependía de otra acción y esa acción falló.

Me inclinaré hacia 407. Se requiere autenticación de proxy 407 Este código es similar a 401 (no autorizado), pero indica que el cliente primero debe autenticarse con el proxy. El proxy DEBE devolver un campo de encabezado Proxy-Authenticate (sección 14.33) que contiene un desafío aplicable al proxy para el recurso solicitado. El cliente PUEDE repetir la solicitud con un campo de encabezado de Autorización de proxy adecuado (sección 14.34). La autenticación de acceso HTTP se explica en "Autenticación HTTP: Autenticación de acceso básica y resumida". como mencionó Iskander.

Sugiere mejor al usuario sobre cuál podría ser el problema. También podría avanzar e implementar el encabezado de autorización de proxy para que sea totalmente coherente con las especificaciones.

El uso de 400 haría que su cliente se rascara la cabeza buscando lo que está haciendo mal al generar la solicitud.

Usar 401 o 403 tiene más sentido conservarlos para su propia autenticación y autorización de API.

502 insinúa al usuario que el problema está corriente arriba, por lo que podría dejarlo colgado hasta que lo solucione.

Me quedaría con 401. El error 401 no autorizado es un código de estado HTTP que significa que la página a la que el usuario intentaba acceder no se puede cargar hasta que el usuario inicie sesión por primera vez con un ID de usuario y contraseña válidos. Si el usuario acaba de iniciar sesión y recibió el error 401 no autorizado, significa que las credenciales que ingresó el usuario no eran válidas por algún motivo. En nuestro caso, la clave API que enviaron no era válida. Hay un diagrama de actividad que estaba usando cuando tengo una confusión con los códigos de error.

Aquí debajo está el enlace para lo mismo:

https://i.stack.imgur.com/ppsbq.jpg

En este caso, el servidor intermediario se ha registrado correctamente y el servidor ascendente se niega a realizar la autenticación en virtud de la clave no válida. Parece que el código 502 (Bad Gateway) se ajusta a esta situación, ya que este código representa un servidor que actúa como una puerta de enlace (el suyo) y recibe una respuesta no válida del servidor ascendente (tercero).