403 Prohibido vs 401 Respuestas HTTP no autorizadas

2785

Para una página web que existe, pero para la cual un usuario no tiene suficientes privilegios (no ha iniciado sesión o no pertenece al grupo de usuarios adecuado), ¿cuál es la respuesta HTTP adecuada para servir?

401 Unauthorized?
403 Forbidden?
¿Algo más?

Lo que he leído sobre cada uno hasta ahora no está muy claro sobre la diferencia entre los dos. ¿Qué casos de uso son apropiados para cada respuesta?

VirtuosiMedia
fuente
358
401 'No autorizado' debe ser 401 'No autenticado', ¡problema resuelto!
Christophe Roussy
47
No recuerdo cuántas veces mis colegas y yo hemos vuelto a stackoverflow para esta pregunta. Tal vez los estándares HTTP deberían considerar modificar los nombres o las descripciones para 401 y 403.
neurita
De hecho, obtengo una versión diferente de este error. como "os_authType era 'any' y se envió una cookie no válida". Tan incapaz de descubrir cómo resolver eso. Busqué en Google mucho tiempo, obtuve razones pero no obtuve una solución.
Sandeep Anand
@Qwerty no, el nuevo RFC7231 obsoleto RFC2616. 403 tiene un significado diferente ahora.
espina de pescado el
1
@fishbone tampoco notó que el código de estado 401 se ha eliminado de ese RFC: D
Barkermn01

Respuestas:

4116

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. Al recibir una respuesta 401, el servidor le dice: "no está autenticado, o no está autenticado o no está autenticado incorrectamente, pero vuelva a autenticarse y vuelva a intentarlo". Para ayudarlo, siempre incluirá un encabezado WWW-Authenticate que describa cómo autenticar.

Esta es una respuesta generalmente devuelta por su servidor web, no por su aplicación web.

También es algo muy temporal; el servidor te pide que lo intentes de nuevo.

Entonces, para la autorización, uso la respuesta Prohibida 403 . Es permanente, está vinculado a la lógica de mi aplicación y es una respuesta más concreta que un 401.

Al recibir una respuesta 403, el servidor le dice: “Lo siento. Sé quién es usted, creo quién dice que es, pero simplemente no tiene permiso para acceder a este recurso. Tal vez si le preguntas al administrador del sistema amablemente, obtendrás permiso. Pero por favor no me molestes de nuevo hasta que tu situación cambie.

En resumen, una respuesta no autorizada 401 debe usarse para la autenticación faltante o incorrecta, y una respuesta prohibida 403 debe usarse después, cuando el usuario se autentica pero no está autorizado para realizar la operación solicitada en el recurso dado.

Otro buen formato gráfico de cómo se deben usar los códigos de estado http.

ingrese la descripción de la imagen aquí

JPReddy
fuente
43
El mensaje predeterminado de IIS 403 es "Este es un error genérico 403 y significa que el usuario autenticado no está autorizado para ver la página", lo que parece estar de acuerdo.
Ben Challenor
333
@JPReddy Tu respuesta es correcta. Sin embargo, esperaría que 401 se llame "No autenticado" y que 403 se llame "No autorizado". Es muy confuso que 401, que tiene que ver con Autenticación, tenga el formato que acompaña al texto "No autorizado" ... A menos que no sea bueno en inglés (lo cual es una gran posibilidad).
p.matsinopoulos
64
@ZaidMasud, según RFC, esta interpretación no es correcta. La respuesta de Cumbayah fue correcta. 401 significa "te estás perdiendo la autorización correcta". Implica "si quieres puedes intentar autenticarte". Entonces, tanto un cliente que no se autenticó correctamente como un cliente autenticado adecuadamente que no haya recibido la autorización obtendrán un 401. 403 significa "No responderé a esto, sea quien sea". RFC establece claramente que "la autorización no ayudará" en el caso de 403.
Davide R.
84
401 es error de autenticación, 403 es error de autorización. Simple como eso.
Shahriyar Imanov
30
Dejaste de lado "Bueno, esa es mi opinión al respecto :)" al copiar de su publicación de blog y desafortunadamente su opinión es incorrecta. Como otros han dicho, 403 significa que no puede acceder al recurso independientemente de quién esté autenticado. Normalmente uso este código de estado para recursos que están bloqueados por rangos de direcciones IP o archivos en mi raíz web a los que no quiero acceso directo (es decir, un script debe servirlos).
Kyle
403

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 para esas credenciales.

403 Prohibido:

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

Actualizar

Según su caso de uso, parece que el usuario no está autenticado. Volvería 401.


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

Oded
fuente
21
Gracias, eso me ayudó a aclararlo. Estoy usando ambos: el 401 para usuarios no autenticados, el 403 para usuarios autenticados con permisos insuficientes.
VirtuosiMedia
52
No voté en contra, pero esta respuesta me parece bastante engañosa. 403 prohibido se usa más apropiadamente en contenido que nunca será servido (como archivos .config en asp.net). es eso o un 404. En mi humilde opinión, no sería apropiado devolver 403 por algo a lo que se pueda acceder, pero simplemente no tenía las credenciales correctas. mi solución sería dar un mensaje de acceso denegado con una forma de cambiar las credenciales. eso o un 401.
Mel
27
"La respuesta DEBE incluir un campo de encabezado WWW-Authenticate (sección 14.47) que contenga un desafío aplicable al recurso solicitado". Parece que si no desea utilizar la autenticación de estilo HTTP, un código de respuesta 401 no es apropiado.
Brilliand
8
Volveré a Billiand aquí. La declaración es "Si la solicitud ya incluye credenciales de autorización". Eso significa que si se trata de una respuesta de una solicitud que proporcionó la credencial (por ejemplo, la respuesta de un intento de autenticación RFC2617). Es esencialmente para permitir que el servidor diga: "Par de cuenta / contraseña incorrecta, intente nuevamente". En la pregunta planteada, el usuario está probablemente autenticado pero no autorizado. 401 nunca es la respuesta adecuada para esas circunstancias.
ldrut
66
Brilliand tiene razón, 401 solo es apropiado para la autenticación HTTP.
Juampi
296

Algo que faltan las otras respuestas es que debe entenderse que la autenticación y autorización en el contexto de RFC 2616 se refiere SOLAMENTE al protocolo de autenticación HTTP de RFC 2617. La autenticación por esquemas fuera de RFC2617 no es compatible con los códigos de estado HTTP y no se considera al decidir si usar 401 o 403.

Breve y breve

No autorizado indica que el cliente no está autenticado con RFC2617 y que 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 admite RFC2617 para el recurso solicitado.

Es decir, si tiene su propio proceso de inicio de sesión de roll-your-own y nunca usa la autenticación HTTP, 403 es siempre la respuesta adecuada y 401 nunca debe usarse.

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 debe 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 de rodar su propia cuenta que haya creado usando páginas de inicio de sesión, etc. Usaré "inicio de sesión" para referirme a la autenticación y autorización por otros métodos que no sean 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 hay autorizaciones que permitirán el acceso al recurso, posiblemente no las hay, pero probémoslo y veamos qué sucede.

403 indica que el recurso no se puede proporcionar 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 de un usuario, una 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 puede o no ayudar, eso está fuera de los estándares y la definición de RFC2616.


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

ldrut
fuente
77
Entonces, ¿qué debemos hacer cuando el usuario solicita una página que requiere autenticación que no sea http? ¿Enviar código de estado 403?
marcovtwout
2
Esta es la respuesta que respondió mis preguntas sobre la distinción.
Patrick
99
Esto es importante: "si tiene su propio proceso de inicio de sesión de roll-your-own y nunca usa la autenticación HTTP, 403 es siempre la respuesta adecuada y 401 nunca debe usarse".
ggg
1
@marcovtwout ¿Enviar un 302 a su página de inicio de sesión, o un 403 que contiene un cuerpo con información sobre cómo iniciar sesión?
Alex
44
¿El RFC7235 no proporciona desafíos de autenticación "roll-your-own" o alternativos? ¿Por qué el flujo de inicio de sesión de mi aplicación no puede presentar su desafío en forma de WWW-Authenticateencabezado? Incluso si un navegador no lo admite, mi aplicación React puede ...
jchook
127
  + -----------------------
  El | ¿EXISTE RECURSO? (si es privado, a menudo se verifica DESPUÉS de la verificación de autenticación)
  + -----------------------
    El | El |
 NO | v SÍ
    v + -----------------------
   404 | ¿ESTÁ INICIADO SESIÓN? (autenticado, también conocido como cookie de sesión o JWT)
   o + -----------------------
   401 El |
   403 NO | El | SI
   3xx vv
              401 + -----------------------
       (404 sin revelar) | ¿PUEDE ACCEDER AL RECURSO? (permiso, autorizado, ...)
              o + -----------------------
             redirigir | El |
             para iniciar sesión NO | El | SI
                               El | El |
                               vv
                               403 OK 200, redirigir, ...
                      (o 404: sin revelación)
                      (o 404: el recurso no existe si es privado)
                      (o 3xx: redirección)

Los controles generalmente se realizan en este orden:

  • 404 si el recurso es público y no existe o redirección 3xx
  • DE OTRA MANERA:
  • 401 si no inició sesión o la sesión expiró
  • 403 si el usuario no tiene permiso para acceder al recurso (archivo, json, ...)
  • 404 si el recurso no existe o no está dispuesto a revelar nada, o la redirección 3xx

NO AUTORIZADO : Código de estado (401) que indica que la solicitud requiere autenticación , generalmente esto significa que el usuario debe iniciar sesión (sesión). Usuario / agente desconocido por el servidor. Se puede repetir con otras credenciales. NOTA: Esto es confuso ya que debería haberse llamado 'no autenticado' en lugar de 'no autorizado'. Esto también puede suceder después de iniciar sesión si la sesión expiró. Caso especial: se puede usar en lugar de 404 para evitar revelar presencia o no presencia de recursos (créditos @gingerCodeNinja)

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 no tiene suficientes credenciales . La solicitud repetida no funcionará, a menos que se cambien las credenciales, lo cual es muy poco probable en un corto período de tiempo. Caso especial: se puede usar en lugar de 404 para evitar revelar la presencia o no de recursos (créditos @gingerCodeNinja)

NO ENCONTRADO : 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, hace como si no existiera. Repetir no funcionará. Este es un uso especial de 404 (github lo hace, por ejemplo).

Como mencionó @ChrisH, hay algunas opciones para la redirección 3xx (301, 302, 303, 307 o no redirigir en absoluto y usar un 401):

Christophe Roussy
fuente
Por ejemplo, he iniciado sesión y puedo acceder a una página, pero no tiene permiso habilitado para mí. ¿Qué código de estado volverá?
barteloma 01 de
@bookmarker Iniciar sesión se llama autenticación, que es el primer paso. Entonces, si no tiene permiso después de iniciar sesión, obtendrá 403 Prohibido (credenciales insuficientes significa que no tiene suficientes permisos).
Christophe Roussy el
3
Explicación clara y simple. Justo lo que necesito.
Estévez
si el usuario no ha iniciado sesión o no ha iniciado sesión, pero no tiene permiso y el contenido no existe en la ubicación, a veces probablemente desee devolver 401/403 en lugar de 404, para que no exponga lo que es o no es No existe si el usuario no está autenticado y no ha iniciado sesión. El simple hecho de saber que existe algo puede indicar algo o romper el NDA. Entonces, a veces, la parte 404 de este diagrama se debe mover debajo de iniciado sesión / autenticado.
gingerCodeNinja
1
@MattKocaj tenga en cuenta que el no revealcaso a veces se puede detectar a través de sutiles diferencias de tiempo y no se debe ver como una característica de seguridad, solo puede ralentizar a los atacantes o ayudar un poco con la privacidad.
Christophe Roussy
113

De acuerdo con 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 la solicitud no se ha cumplido, DEBERÍA describir el motivo del rechazo en la entidad. Si el servidor no desea que esta información esté disponible para el cliente, se puede utilizar el código de estado 404 (No encontrado)

En otras palabras, si el cliente PUEDE obtener acceso al recurso mediante la autenticación, se debe enviar 401.

Cumbayah
fuente
55
¿Y si no está claro si pueden acceder o no? Digamos que tengo 3 niveles de usuario: Público, Miembros y Miembros Premium. Suponga que la página es solo para miembros Premium. Un usuario público básicamente no está autenticado y podría estar en Miembros o Miembros Premium cuando inician sesión. Para el nivel de usuario Miembro, un 403 parecería apropiado. Para miembros Premium, el 401. Sin embargo, ¿a qué sirve al público?
VirtuosiMedia
27
En mi humilde opinión, esta es la respuesta más precisa. depende de la aplicación, pero en general, si un usuario autenticado no tiene suficientes derechos sobre un recurso, es posible que desee proporcionar una forma de cambiar las credenciales o enviar un 401. Creo que 403 es el más adecuado para el contenido que nunca se sirve. En asp.net esto significaría archivos web.config * .resx, etc., porque no importa qué usuario inicie sesión, estos archivos NUNCA se servirán, por lo que no tiene sentido volver a intentarlo.
Mel
66
+1, pero un incierto +1. La conclusión lógica es que un 403 nunca debe devolverse ya que 401 o 404 serían una respuesta estrictamente mejor.
CurtainDog
12
@ Mel Creo que un archivo al que no debe acceder el cliente debe ser un 404. Es un archivo interno del sistema; el exterior ni siquiera debería saber que existe. Al devolver un 403, le informa al cliente que existe, no es necesario que revele esa información a los piratas informáticos. La especificación para 403 diceAn origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
Juan Mendes
3
Si bien esto me parece que es probablemente una interpretación precisa del antiguo RFC 2616, tenga en cuenta que RFC 7231 define la semántica de un 403 de manera diferente , y de hecho declara explícitamente que "el cliente PUEDE repetir la solicitud con credenciales nuevas o diferentes". Entonces, aunque esta respuesta fue precisa en 2010, está completamente equivocada hoy, porque el significado del código de estado se ha reescrito bajo nuestros pies. (¡Molesto, los cambios del apéndice RFC 2616 no reconocen el cambio!)
Mark Amery
46

Suponiendo que la autenticación HTTP ( WWW-Autenticación y encabezados de autorización ) esté en uso , si la autenticación como otro usuario otorgaría acceso al recurso solicitado, se devolverá 401 No autorizado.

403 Prohibido se usa cuando el acceso al recurso está prohibido para todos o restringido a una red determinada o permitido solo a través de SSL, siempre que no esté relacionado con la autenticación HTTP.

Si la autenticación HTTP no está en uso y el servicio es un esquema de autenticación basado en cookies como es la norma hoy en día, entonces se debe devolver un 403 o un 404.

Con respecto a 401, esto es 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 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 campo de encabezado WWW-Authenticate (Sección 4.4) que contenga al menos un desafío aplicable al recurso de destino. Si la solicitud incluía credenciales de autenticación, la respuesta 401 indica que se ha rechazado la autorización para esas credenciales.. El cliente PUEDE repetir la solicitud con un campo de encabezado de autorización nuevo o reemplazado (Sección 4.1). Si la respuesta 401 contiene el mismo desafío que la respuesta anterior, y el agente del usuario ya ha intentado la autenticación al menos una vez, entonces el agente del usuario DEBE presentar la representación adjunta al usuario, ya que generalmente contiene información de diagnóstico relevante.

La semántica de 403 (y 404) ha cambiado con el tiempo. Esto es de 1999 (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 del rechazo en la entidad. Si el servidor no desea que esta información esté disponible para el cliente,
se puede usar el código de estado 404 (No encontrado).

En 2014, RFC 7231 (Protocolo de transferencia de hipertexto (HTTP / 1.1): semántica y contenido) cambió 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é se ha prohibido la solicitud puede describir ese motivo en la carga útil 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 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 de destino prohibido PUEDE responder con un código de estado de
404 (No encontrado).

Por lo tanto, un 403 (o un 404) ahora podría significar cualquier cosa. Proporcionar nuevas credenciales puede ayudar ... o puede que no.

Creo que la razón por la cual esto ha cambiado es que RFC 2616 asumió que la autenticación HTTP se usaría cuando, en la práctica, las aplicaciones web actuales crean esquemas de autenticación personalizados utilizando, por ejemplo, formularios y cookies.

Erwan Legrand
fuente
2
Esto es interesante. Basado en RFC 7231 y RFC 7235, no veo una distinción obvia entre 401 y 403
Brian
2
403 significa "Te conozco pero no puedes ver este recurso". No hay razón para la confusión.
Michael Blackburn
"Si la solicitud incluía credenciales de autenticación, la respuesta 401 indica que se ha rechazado la autorización para esas credenciales. El cliente PUEDE repetir la solicitud con un campo de encabezado de autorización nuevo o reemplazado (Sección 4.1)". Sin embargo, luego "4.2. El campo de encabezado 'Autorización' permite que un agente de usuario se autentique con un servidor de origen". Parece que en RFC7235 usan el término "autorización" como si fuera "autenticación". En ese caso, podría parecer que un usuario autenticado pero no autorizado no debería obtener un 401, sino un 403
arcuri82 el
29

Esta es una pregunta anterior, pero una opción que nunca se mencionó fue devolver un 404. Desde una perspectiva de seguridad, la respuesta más votada sufre una posible vulnerabilidad de fuga de información . Digamos, por ejemplo, que la página web segura en cuestión es una página de administración 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á que un usuario malintencionado sepa que hay una página / registro allí, y mucho menos que no tiene acceso. Cuando estoy creando algo como esto, intentaré registrar solicitudes no autenticadas / no autorizadas en un registro interno, pero devolveré un 404.

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

Patrick White
fuente
3
El uso de un 404 ha sido mencionado en respuestas anteriores. Estás en el punto re: fuga de información y esto debería ser una consideración importante para cualquiera que desarrolle su propio esquema de autenticación / autorización. +1 por mencionar OWASP.
Dave Watts
Irónicamente, el enlace OWASP ahora va a una página 404. Encontré algo similar (creo) en owasp.org/index.php/…
anned20
Gracias por el aviso, lo actualicé!
Patrick White
Depende de la API y de cómo se otorga el acceso. Pero "filtrar" no es un problema si devuelve 401 para nombre de usuario / contraseña, ¿es lo mismo que para un formulario web?
James
26
  • 401 No autorizado : No sé quién eres. Este es un error de autenticación.
  • 403 Prohibido : Sé quién eres, pero no tienes permiso para acceder a este recurso. Este es un error de autorización.
Akshay Misal
fuente
No estoy seguro de que específicamente "siempre" signifique que el remitente era desconocido. Todo lo que pidieron no fue autorizado.
James
22

Esta pregunta se hizo hace algún tiempo, pero el pensamiento de la gente sigue adelante.

La Sección 6.5.3 en este borrador (escrito por Fielding y Reschke) le da al código de estado 403 un significado ligeramente diferente al que se documenta en RFC 2616 .

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

He enfatizado la parte que creo que es más sobresaliente.

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é se ha prohibido la solicitud puede describir ese motivo en la carga útil 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 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).

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

Dave Watts
fuente
2
El borrador fue aprobado y ahora es RFC 7231.
Vebjorn Ljosa
13

TL; DR

  • 401: un rechazo que tiene que ver con la autenticación
  • 403: un rechazo que no tiene NADA que ver con la autenticación

Ejemplos prácticos

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

Si nginx encuentra un archivo, pero no tiene derechos de acceso (usuario / grupo) para leerlo / accederlo, responderá con403 Forbidden

RFC (2616 Sección 10)

401 No autorizado (10.4.2)

Significado 1: Necesito autenticar

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 para esas credenciales. ...

403 Prohibido (10.4.4)

Significado: no relacionado con la autenticación

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

Más detalles:

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

  • DEBE describir la razón del rechazo en la entidad

  • En su lugar, se puede usar el código de estado 404 (No encontrado)

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

Levita
fuente
11

no han iniciado sesión o no pertenecen al grupo de usuarios adecuado

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

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

Nota sobre el RFC basada en los comentarios recibidos a esta respuesta:

Si el usuario no ha iniciado sesión, no está autenticado, cuyo equivalente HTTP es 401 y se denomina engañosamente No autorizado en el RFC. Como se indica en la sección 10.4.2 para 401 no autorizado :

"La solicitud requiere autenticación de usuario ".

Si no está autenticado, 401 es la respuesta correcta. Sin embargo, si no está autorizado, en el sentido semánticamente correcto, 403 es la respuesta correcta.

Zaid Masud
fuente
55
Esto no es correcto. Consulte RFC y la respuesta de @ Cumbayah.
Davide R.
77
@DavideR. El RFC utiliza la autenticación y la autorización de manera intercambiable. Creo que tiene más sentido cuando se lee con el significado de autenticación .
Zaid Masud
Esta respuesta se invierte. No autorizado no es lo mismo que No autenticado. @DavideR tiene razón. La autenticación y la autorización NO son intercambiables
BozoJoe
2
2616 debe ser quemado. Varios RFC más nuevos son mucho más claros que existe la necesidad de diferenciar entre "No te conozco" y "Te conozco, pero no puedes acceder a esto". No hay una razón legítima para reconocer la existencia de un recurso que nunca se cumplirá (o no se cumplirá a través de http), que es lo que sugieren los 403-truthers.
Michael Blackburn
6

Estos son los significados:

401 : Usuario no autenticado (correctamente), el recurso / página requiere autenticación

403 : Usuario autenticado, pero su rol o permisos no permiten acceder al recurso solicitado, por ejemplo, el usuario no es administrador y la página solicitada es para administradores

Luca C.
fuente
Esta es una gran respuesta TLDR a esta pregunta.
Kousha
5

Esto es más simple en mi cabeza que en cualquier otro lugar aquí, así que:

401: Necesita autenticación básica HTTP para ver esto.

403: No puede ver esto, y la autenticación básica HTTP no ayudará.

Si el usuario solo necesita iniciar sesión con el formulario de inicio de sesión HTML estándar de su sitio, 401 no sería apropiado porque es específico de la autenticación básica HTTP.

No recomiendo usar 403 para negar el acceso a cosas como /includes, porque en lo que respecta a la web, esos recursos no existen en absoluto y, por lo tanto, deberían 404.

Esto deja 403 como "necesita iniciar sesión".

En otras palabras, 403 significa "este recurso requiere alguna forma de autenticación distinta de la autenticación básica HTTP".

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

Vladimir Kornea
fuente
5

Creo que es importante tener en cuenta 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 no válida, mientras que 403 significa falta de permiso.

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

  • Un recurso requiere autenticación pero no se especificaron credenciales .

401 : el cliente debe especificar las credenciales.

  • Las credenciales especificadas están en un formato no válido .

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

  • Las credenciales especificadas hacen referencia a un usuario que no existe .

401 : el cliente debe especificar credenciales válidas.

  • Las credenciales especificadas no son válidas, pero especifique un usuario válido (o no especifique un usuario si no se requiere un usuario especificado).

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

  • Las credenciales especificadas han caducado .

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 son suficientes para el recurso en particular , aunque es posible que las credenciales con más permiso puedan hacerlo .

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

  • El recurso particular 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álidos, pero el particular, el cliente se bloquean mediante su utilización.

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

Grant Gryczan
fuente
4

En inglés:

401

Se le permite el acceso potencial, pero por alguna razón en esta solicitud se le negó. ¿Como una contraseña incorrecta? Inténtalo de nuevo, con la solicitud correcta obtendrás una respuesta exitosa.

403

No se te permite nunca. Su nombre no está en la lista, nunca entrará, se irá, no envíe una solicitud de reintento, siempre será rechazado. Vete.

James
fuente
1

Dado los últimos RFC sobre el tema ( 7231 y 7235 ), el caso de uso parece bastante claro (cursiva agregada):

  • 401 es para personas no autenticadas ("carece de autenticación válida"); es decir, "No sé quién eres o no confío en que seas quien dices que eres".

401 no autorizado

El código de estado 401 (no autorizado) indica que la solicitud no se ha aplicado porque carece de credenciales de autenticación válidas para el recurso de destino. El servidor que genera una respuesta 401 DEBE enviar un campo de encabezado WWW-Authenticate (Sección 4.1) que contiene al menos un desafío aplicable al recurso de destino.

Si la solicitud incluía credenciales de autenticación, la respuesta 401 indica que se ha rechazado la autorización para esas credenciales. El agente de usuario PUEDE repetir la solicitud con un campo de encabezado de autorización nuevo o reemplazado (Sección 4.2). Si la respuesta 401 contiene el mismo desafío que la respuesta anterior, y el agente del usuario ya ha intentado la autenticación al menos una vez, entonces el agente del usuario DEBE presentar la representación adjunta al usuario, ya que generalmente contiene información de diagnóstico relevante.

  • 403 es para personas no autorizadas ("se niega a autorizar"); es decir, 'Sé quién eres, pero no tienes permiso para acceder a este recurso'.

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é se ha prohibido la solicitud puede describir ese motivo en la carga útil 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 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).

cjbarth
fuente
2
-1; Estos pasajes ya se han citado en otras respuestas aquí, y el suyo no agrega nada nuevo. Yo diría que evidentemente no está claro cuál es la distinción; Resume los dos códigos como "carece de autenticación válida" y "se niega a autorizar", pero no puedo concebir ninguna situación en la que una de esas descripciones breves se aplicaría donde la otra no pudiera interpretarse también.
Mark Amery
Aquí hay muchas respuestas que cubren muchos RFC y se editan y actualizan enturbiando las aguas. Incluí un enlace para explicar qué authenticatedes y qué authorizedes y omití todos los RFC obsoletos para que la aplicación sea clara.
cjbarth
Su edición aclara su interpretación de los dos códigos, que parece coincidir con la interpretación de muchas otras personas. Sin embargo, personalmente creo que la interpretación tiene poco sentido. El uso de la frase " Si se proporcionaron credenciales de autenticación" en la descripción 403 implica que un 403 puede ser apropiado incluso si no se proporcionaron credenciales, es decir, el caso "no autenticado". Mientras tanto, para mí, la interpretación más natural de la frase "para el recurso objetivo" que se incluye en la descripción del 401 es que un 401 puede usarse para un usuario autenticado pero no autorizado.
Mark Amery
-6

En el caso de 401 vs 403, esto ha sido respondido muchas veces. Esto es esencialmente un debate de 'entorno de solicitud HTTP', no un debate de 'aplicación'.

Parece que hay una pregunta sobre el problema de roll-your-own-login (aplicación).

En este caso, simplemente no iniciar sesión no es suficiente para enviar un 401 o un 403, a menos que use HTTP Auth frente a una página de inicio de sesión (no vinculada a la configuración de HTTP Auth). Parece que puede estar buscando un "201 Creado", con una pantalla de inicio de sesión automático (en lugar del recurso solicitado) para el acceso de nivel de aplicación a un archivo. Esto dice:

"Te escuché, está aquí, pero intenta esto en su lugar (no puedes verlo)"

Shawn
fuente
¿Qué se está creando exactamente?
Grant Gryczan