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?

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.

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 .

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 .

  + -----------------------
  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):

• Diferencia entre los códigos de redireccionamiento HTTP
• ¿Por cuánto tiempo los navegadores almacenan en caché los HTTP 301?
• ¿Cuál es el código de estado HTTP correcto al redirigir a una página de inicio de sesión?
• ¿Cuál es la diferencia entre un redireccionamiento 302 y 307?

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.

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.

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.

• 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.

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.

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)

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.

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

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

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.

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.

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).

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)"