Pregunta 403 Forbidden vs 401 respuestas HTTP no autorizadas


Para una página web que existe, pero para la cual un usuario que no tiene privilegios suficientes (no está conectado o no pertenece al grupo de usuarios adecuado), ¿cuál es la respuesta HTTP adecuada para atender? 401? 403? ¿Algo más? Lo que he leído hasta ahora no es muy claro sobre la diferencia entre los dos. ¿Qué casos de uso son apropiados para cada respuesta?


1896
2017-07-21 07:21


origen


Respuestas:


Una explicación clara de Daniel Irvine:

Hay un problema con 401 no autorizado, el código de estado HTTP para errores de autenticación. Y eso es todo: es para autenticación, no para autorización.   Recibir una respuesta 401 es que el servidor le dice, "usted no está   autenticado, ya sea no autenticado o autenticado   incorrectamente, pero por favor vuelve a autenticarte y vuelve a intentarlo. "Para ayudarte,   siempre incluirá una WWW-Authenticate encabezado que describe cómo   para autenticarse

Esta es una respuesta generalmente devuelta por su servidor web, no su web   solicitud.

También es algo muy temporal; el servidor te está pidiendo que pruebes   de nuevo.

Entonces, para autorización, uso el 403 prohibido respuesta. Sus   permanente, está ligado a mi lógica de aplicación, y es una más concreta   respuesta que un 401.

Al recibir una respuesta 403, el servidor le dice: "Lo siento". Lo sé   quién eres, creo quién eres, pero no tienes   permiso para acceder a este recurso Tal vez si le preguntas al sistema   administrador muy bien, obtendrá el permiso. Pero por favor no te molestes   yo otra vez hasta que tu situación cambie ".

En resumen, un 401 no autorizado la respuesta se debe usar para desaparecer   o autenticación incorrecta, y una 403 prohibido la respuesta debe ser utilizada   después, cuando el usuario está autenticado pero no está autorizado a   realizar la operación solicitada en el recurso dado.

Otro buen formato pictórico de cómo deberían usarse los códigos de estado http.


2828
2017-08-04 06:24



Ver RFC2616:

401 no autorizado:

Si la solicitud ya incluía credenciales de autorización, la respuesta 401 indica que se ha rechazado la autorización de esas credenciales.

403 Prohibido:

El servidor entendió la solicitud, pero se niega a cumplirla.

Actualizar

Desde su caso de uso, parece que el usuario no está autenticado. Yo regresaría 401.


Editar: RFC2616 está obsoleto, ver RFC7231 y RFC7235.


336
2017-07-21 07:28



Algo que las otras respuestas faltan es que debe entenderse que Autenticación y Autorización en el contexto de RFC 2616 se refiere SÓLO al protocolo de Autenticación HTTP de RFC 2617. La autenticación por esquemas fuera de RFC2617 no son compatibles con los códigos de estado HTTP y no se consideran al decidir si usar 401 o 403 ...

Breve y Terse

Unaauthorized indica que el cliente no está autenticado con RFC2617 y el servidor está iniciando el proceso de autenticación. Prohibido indica que el cliente está autenticado con RFC2617 y no tiene autorización o que el servidor no es compatible con RFC2617 para el recurso solicitado.

Es decir, si tiene su propio proceso de inicio de sesión y no usa Autenticación HTTP, 403 es siempre la respuesta adecuada y 401 nunca debe utilizarse.

Detallado y en profundidad

De RFC2616

10.4.2 401 no autorizado

La solicitud requiere autenticación de usuario. La respuesta DEBE incluir un campo de encabezado WWW-Authenticate (sección 14.47) que contenga un desafío aplicable al recurso solicitado. El cliente PUEDE repetir la solicitud con un campo de encabezado de Autorización adecuado (sección 14.8).

y

10.4.4 403 prohibido   El servidor entendió la solicitud, pero se niega a cumplirla. La autorización no ayudará y la solicitud NO DEBE repetirse.

Lo primero que hay que tener en cuenta es que "Autenticación" y "Autorización" en el contexto de este documento se refieren específicamente a los protocolos de autenticación HTTP de RFC 2617. No se refieren a ningún protocolo de autenticación "roll-your-own" que haya creado. usando las páginas de inicio de sesión, etc. Usaré "inicio de sesión" para referirme a la autenticación y autorización por métodos distintos de RFC2617

Entonces la verdadera diferencia no es cuál es el problema o incluso si hay una solución. La diferencia es lo que el servidor espera que el cliente haga a continuación.

401 indica que no se puede proporcionar el recurso, pero el servidor SOLICITA que el cliente inicie sesión a través de la Autenticación HTTP y ha enviado encabezados de respuesta para iniciar el proceso. Posiblemente haya autorizaciones que permitan el acceso al recurso, posiblemente no, pero hagámoslo y veamos qué sucede.

403 indica que no se puede proporcionar el recurso y que, para el usuario actual, no hay forma de resolverlo a través de RFC2617 y no tiene sentido intentarlo. Esto puede deberse a que se sabe que ningún nivel de autenticación es suficiente (por ejemplo, debido a una lista negra de IP), pero puede deberse a que el usuario ya está autenticado y no tiene autoridad. El modelo RFC2617 es para un usuario y una sola credencial, por lo que se puede ignorar el caso en el que el usuario puede tener un segundo conjunto de credenciales que podrían autorizarse. No sugiere ni implica que algún tipo de página de inicio de sesión u otro protocolo de autenticación que no sea RFC2617 pueda o no ayudar, que está fuera de los estándares y la definición de RFC2616.


Editar: RFC2616 está obsoleto, ver RFC7231 y RFC7235.


254
2018-02-05 17:14



De acuerdo a RFC 2616 (HTTP / 1.1) 403 se envía cuando:

El servidor entendió la solicitud, pero se niega a cumplirla. La autorización no ayudará y la solicitud NO DEBE repetirse. Si el método de solicitud no era HEAD y el servidor desea hacer público el motivo por el cual no se ha cumplido la solicitud, DEBERÍA describir el motivo de la negativa en la entidad. Si el servidor no desea poner esta información a disposición del cliente, se puede usar el código de estado 404 (No encontrado) en su lugar

En otras palabras, si el cliente PUEDE obtener acceso al recurso autenticando, se debe enviar 401.


94
2017-07-21 07:26



TL; versión DR

    GET recurso, existe?
    | |
    | |
    v v
NO: 404 SÍ: ¿Está autenticado?
             | |
             | |
             v v
           NO: 401 SÍ: ¿Se puede acceder al recurso?
           (o: 404) | |
           o 301 | |
           redirigir v v
           para iniciar sesión NO: 403 OK 200, 301, ...

Los cheques generalmente se hacen en este orden:

  • 401 si no ha iniciado sesión o la sesión ha expirado
  • 403 si el usuario no tiene permiso para acceder al recurso
  • 404 si el recurso no existe

NO AUTORIZADO: Código de estado (401) que indica que la solicitud requiere autenticación. Usuario / agente desconocido por el servidor. Se puede repetir con otras credenciales. NOTA: Esto es confuso ya que esto debería haberse denominado 'no autenticado' en lugar de 'no autorizado'.

PROHIBIDO: Código de estado (403) que indica que el servidor entendió la solicitud pero se negó a cumplirla. Usuario / agente conocido por el servidor, pero tiene credenciales insuficientes. Repetir la solicitud no funcionará.

EXTRAVIADO: Código de estado (404) que indica que el recurso solicitado no está disponible. Usuario / agente conocido pero el servidor no revelará nada sobre el recurso, lo hace como si no existiera. Repetir no funcionará. Este es un uso especial de 404 (github lo hace, por ejemplo).


46
2018-02-23 11:00



Si la autenticación como otro usuario otorgaría acceso al recurso solicitado, entonces 401 no autorizado debe ser devuelto. 403 Forbidden se usa principalmente cuando el acceso al recurso está prohibido para todos o está restringido a una red determinada o solo se permite a través de SSL, independientemente de si está relacionado con la autenticación.

De RFC 7235 (Protocolo de transferencia de hipertexto (HTTP / 1.1): Autenticación):

3.1. 401 no autorizado

El código de estado 401 (no autorizado) indica que la solicitud tiene   no se ha aplicado porque carece de credenciales de autenticación válidas   para el recurso de destino. El servidor de origen DEBE enviar un   WWW-Authenticate header field (Sección 4.4) que contiene al menos una   desafío aplicable al recurso objetivo. Si la solicitud   credenciales de autenticación incluidas, luego la respuesta 401   indica que la autorización ha sido rechazada por aquellos   cartas credenciales. El cliente PUEDE repetir la solicitud con un nuevo o   el campo de encabezado de Autorización reemplazado (Sección 4.1). Si el 401   respuesta contiene el mismo desafío que la respuesta anterior, y el   el agente de usuario ya intentó la autenticación al menos una vez, luego   el agente de usuario DEBERÍA presentar la representación adjunta al   usuario, ya que generalmente contiene información de diagnóstico relevante.

Y esto es de RFC 2616:

10.4.4 403 prohibido

El servidor entendió la solicitud, pero se niega a cumplirla.
La autorización no ayudará y la solicitud NO DEBE repetirse.
  Si el método de solicitud no era HEAD y el servidor desea hacer
  público por qué la solicitud no se ha cumplido, DEBERÍA describir el   motivo de la negativa en la entidad. Si el servidor no desea   poner esta información a disposición del cliente, el código de estado 404
  (No encontrado) se puede utilizar en su lugar.

Editar: RFC 7231 (Protocolo de transferencia de hipertexto (HTTP / 1.1): Semántica y contenido) cambia el significado de 403:

6.5.3. 403 prohibido

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é la solicitud ha sido prohibida puede   describa esa razón en la carga útil de respuesta (si corresponde).

Si se proporcionaron credenciales de autenticación en la solicitud, el
  el servidor los considera insuficientes para otorgar acceso. El cliente
  NO DEBE repetir automáticamente la solicitud con el mismo
  cartas credenciales. El cliente PUEDE repetir la solicitud con nuevo o diferente   cartas credenciales. Sin embargo, una solicitud puede estar prohibida por razones
  sin relación con 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).

Por lo tanto, un 403 ahora podría significar cualquier cosa. Proporcionar nuevas credenciales podría ayudar ... o podría no ser así.


37
2018-02-27 09:44



Esta es una pregunta más antigua, pero una opción que nunca se planteó realmente fue la de devolver un 404. Desde una perspectiva de seguridad, la respuesta más votada tiene un potencial vulnerabilidad de fuga de información. Digamos, por ejemplo, que la página web segura en cuestión es una página de administrador del sistema, o quizás más comúnmente, es un registro en un sistema al que el usuario no tiene acceso. Idealmente, no querría que un usuario malicioso siquiera supiera que hay una página / registro allí, y mucho menos que no tenga acceso. Cuando estoy creando algo así, intentaré registrar solicitudes no autenticadas / no autorizadas en un registro interno, pero devolveré un 404.

OWASP tiene algunos más información acerca de cómo un atacante podría usar este tipo de información como parte de un ataque.


20
2017-12-25 09:09



Esta pregunta fue formulada hace algún tiempo, pero las ideas de las personas continúan.

Sección 6.5.3 en este borrador (redactado por Fielding y Reschke) el código de estado 403 tiene un significado ligeramente diferente al documentado en RFC 2616.

Refleja lo que sucede en los esquemas de autenticación y autorización empleados por varios servidores web y frameworks populares.

He enfatizado el bit que creo que es más destacado.

6.5.3. 403 prohibido

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é la solicitud ha sido prohibida puede describir esa razón en la carga de respuesta (si corresponde).

Si se proporcionaron credenciales de autenticación en la solicitud, el servidor las considera insuficientes para otorgar acceso. El cliente NO DEBE repetir 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 no relacionadas con las credenciales.

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

Cualquiera que sea la convención que utilice, lo importante es proporcionar uniformidad en su sitio / API.


19
2018-05-22 10:54



TL; DR

  • 401: una negativa que tiene que ver con la autenticación
  • 403: Una negativa que NO tiene NADA que ver con la autenticación

Ejemplos prácticos

Si apache  requiere autenticación (vía .htaccess), y golpeas Cancel, responderá con un 401 Authorization Required

Si nginx encuentra un archivo, pero no tiene derechos de acceso (usuario / grupo) para leer / acceder, responderá con 403 Forbidden

RFC (2616 Sección 10)

401 no autorizado (10.4.2)

Significado 1: Necesidad de autenticarse

La solicitud requiere autenticación de usuario. ...

Significado 2: Autenticación insuficiente

... Si la solicitud ya incluía credenciales de autorización, la respuesta 401 indica que se ha rechazado la autorización de esas credenciales. ...

403 Prohibido (10.4.4)

Sentido: No relacionado con la autenticación

... La autorización no ayudará ...

Más detalles:

  • El servidor entendió la solicitud, pero se niega a cumplirla.

  • DEBERÍA describir el motivo de la negativa en la entidad

  • El código de estado 404 (No encontrado) se puede usar en su lugar

    (Si el servidor quiere mantener esta información del cliente)


9
2018-02-25 09:03



no están conectados o no pertenecen al grupo de usuarios adecuado

Usted ha declarado dos casos diferentes; cada caso debe tener una respuesta diferente:

  1. Si no han iniciado sesión en absoluto, debe devolver 401 no autorizado
  2. Si han iniciado sesión pero no pertenecen al grupo de usuarios adecuado, debe devolver 403 prohibido

7
2017-10-01 14:34



Creo que es importante considerar que, para un navegador, 401 inicia un diálogo de autenticación para que el usuario ingrese nuevas credenciales, mientras que 403 no lo hace. Los navegadores piensan que, si se devuelve un 401, el usuario debe volver a autenticarse. Entonces 401 significa autenticación inválida mientras que 403 significa falta de permiso.

Aquí hay algunos casos bajo esa lógica donde un error sería devuelto por autenticación o autorización, con frases importantes en negrita.

  • Un recurso requiere autenticación pero sin credenciales fueron especificado.

401: El cliente debe especificar credenciales.

  • Las credenciales especificadas están en una formato inválido.

400: Eso no es ni 401 ni 403, ya que los errores de sintaxis siempre deben devolver 400.

  • Las credenciales especificadas especifican un usuario cual no existe.

401: El cliente debe especificar credenciales válidas.

  • El especificado cartas credenciales son inválido pero especifique un usuario válido (o no especifique un usuario como un usuario especificado no es necesario).

401: Nuevamente, el cliente debe especificar credenciales válidas.

  • El especificado cartas credenciales tener muerto.

401: Esto es prácticamente lo mismo que tener credenciales no válidas en general, por lo que el cliente debe especificar credenciales válidas.

  • Las credenciales especificadas son completamente válidas pero no lo son satisfacer lo particular recurso, aunque es posible que las credenciales con más permisos sí.

403: La especificación de credenciales válidas no otorgaría acceso al recurso, ya que las credenciales actuales ya son válidas, pero solo no tienen permiso.

  • Lo particular recurso es inaccesible independientemente de las credenciales.

403: Esto es independientemente de las credenciales, por lo que especificar credenciales válidas no puede ayudar.

  • Las credenciales especificadas son completamente válidas, pero el particular cliente es obstruido de usarlos.

403: Si el cliente está bloqueado, especificar nuevas credenciales no hará nada.


3
2018-06-02 23:34