Véase RFC2616 :

401 No autorizado:

Si la solicitud ya incluía credenciales de autorización, entonces la respuesta 401 indica que la autorización ha sido rechazada para esas credenciales.

403 Prohibido:

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

Actualización

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

Edit: RFC2616 está obsoleta, véase 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 SOLO al protocolo de autenticación HTTP de RFC 2617. La autenticación por esquemas fuera de RFC2617 no se admite en los códigos de estado HTTP y no se tiene en cuenta al decidir si se utiliza 401 o 403..

Breve y Conciso

Unauthorized indica que el cliente no está autenticado por RFC2617 y que el servidor está iniciando el proceso de autenticación. Forbidden indica que el cliente está autenticado por RFC2617 y no tiene autorización o que el servidor no admite RFC2617 para el recurso solicitado.

Lo que significa que si tiene su propio proceso de inicio de sesión y nunca usa autenticación HTTP, 403 siempre es 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 tenga en cuenta 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 utilizando páginas de inicio de sesión, etc. Usaré "login" para hacer referencia a la autenticación y autorización por métodos que no sean RFC2617

Así que la diferencia real no es cuál es el problema o incluso si hay una solución. La diferencia es lo que el servidor espera el cliente a hacer después.

401 indica que el recurso no se puede proporcionar, pero el servidor está SOLICITANDO 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 hay, pero vamos a darle una oportunidad y ver qué sucede.

403 indica que el recurso no se puede proporcionar y no hay, para el usuario actual, ninguna manera de resolver esto 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 un usuario, una credenciales, por lo que el caso en el que el usuario puede tener un segundo conjunto de credenciales que podrían ser autorizadas puede ser ignorado. No sugiere ni implica que algún tipo de página de inicio de sesión u otro protocolo de autenticación no RFC2617 puede o puede no ayuda - eso está fuera de los estándares y definición RFC2616.

Edit: RFC2616 está obsoleta, véase RFC7231 y RFC7235.

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 por qué la solicitud no se ha cumplido, debe describir el motivo de la denegación 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

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

   GET, resource exists ?
    |      |
 NO |      | YES
    v      v
   404     Is authenticated (logged-in) ?
             |              |
          NO |              | YES
             v              v
             401            Can access resource (has permissions) ?
           (or: 404)        |            |
           or 301        NO |            | YES
           redirect         v            v
           to login        403           OK 200, 301, ...

Las comprobaciones se suelen hacer 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: el código de Estado (401) indicando que la solicitud se requiere autenticación, normalmente esto significa que el usuario debe ser iniciado sesión (sesión). Usuario / agente desconocido por el servidor. Puede repetir con otras credenciales. NOTA: Esto es confuso ya que debería haber sido nombrado 'unauthenticated' en lugar de'unauthorized'. Esto también puede fallar si la sesión ha expirado.

FORBIDDEN: 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 con credenciales insuficientes. Repetir la solicitud no funcionará, a menos que se cambien las credenciales, lo cual es muy poco probable en un corto período de tiempo.

NO ENCONTRADO : Código de estado (404) que indica que el el recurso no está disponible. Usuario / agente conocido pero 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).

Si autenticarse como otro usuario otorgaría acceso al recurso solicitado, entonces debería devolverse 401 Unauthorized. 403 Forbidden se usa principalmente cuando el acceso al recurso está prohibido para todos o restringido a una red determinada o permitido solo a través de SSL, lo que sea, siempre y cuando no esté relacionado con la autenticación.

De RFC 7235 (Protocolo de Transferencia de Hipertexto (HTTP/1.1): Autenticación):

3.1. 401 No autorizados

El estado 401 (No autorizado) el código indica que la solicitud tiene no se ha aplicado porque carece de credenciales de autenticación válidas para el recurso objetivo. El servidor de origen DEBE enviar un WWW-Authenticate campo de encabezado (Sección 4.4) que contiene al menos un desafío aplicable al recurso objetivo. Si la solicitud credenciales de autenticación incluidas, luego la respuesta 401 indica que se ha denegado la autorización a los credenciales. El cliente PUEDE repetir la solicitud con un nuevo or 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 ha intentado la autenticación al menos una vez, entonces el agente de usuario DEBE presentar la representación adjunta a la usuario, ya que por lo general contiene información de diagnóstico relevante.

Y esto es de RFC 2616:

10.4.4 403 Prohibido

El servidor entendió la petición, 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, debe describir la 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 entendido la solicitud, pero se niega a autorizarlo. 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 la hay).

Si las credenciales de autenticación fueron proporcionadas en la solicitud, el
el servidor los considera insuficientes para otorgar acceso. El cliente
NO debe repetir automáticamente la solicitud con la misma
credencial. El cliente PUEDE repetir la solicitud con nuevos o diferentes credencial. Sin embargo, una solicitud puede ser prohibida por razones
sin relación con las credenciales.

Un servidor de origen que desea "ocultar" la existencia actual de un
el recurso objetivo prohibido puede responder con un código de estado de
404 (No Encontrar).

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

Esta es una pregunta antigua, pero una opción que nunca se planteó fue devolver un 404. Desde una perspectiva de seguridad, la respuesta más votada sufre de una potencial 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. Lo ideal es que no quieras que un usuario malicioso sepa que hay una página / registro allí, y mucho menos que no tienen acceso. Cuando estoy construyendo 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.

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) da al código de estado 403 un significado ligeramente diferente al documentado en RFC 2616.

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

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

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 ú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 la solicitud con las mismas credenciales. El 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 con un código de estado de 404 (No encontrado).

Sea cual sea la convención que utilice, lo importante es proporcionar uniformidad en todo 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 (a través de .htaccess), y pulsa Cancel, responderá con un 401 Authorization Required

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

RFC (Sección 2616 10)

401 No autorizado (10.4.2)

Significado 1: Necesidad de 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 a autenticación

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

Más detalles:

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

• Debe describir el motivo de la denegación 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 de cliente)

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

Usted ha indicado 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 están conectados pero no pertenecen al grupo de usuarios adecuado, debe devolver 403 Forbidden

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. Así que 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.

• A el 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 especifique credenciales válidas.

• Las credenciales especificadas son no válidas pero especifican un usuario válido (o no especifican un usuario ya que no se requiere un usuario especificado).

401: Una vez más, el cliente debe especificar credenciales válidas.

• The specified credentials have expired.

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

• Las credenciales especificadas son completamente válidas pero no bastan 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 en particular es inaccesible independientemente de credencial.

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 cliente está bloqueado de usarlas.

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

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 puedes ver esto, y HTTP basic auth no ayudará.

Si el usuario solo necesita iniciar sesión usando el formulario de inicio de sesión HTML estándar de su sitio, 401 no sería apropiado porque es específico de HTTP basic auth.

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 debe por lo tanto 404.

Esto deja 403 como "necesita estar conectado".

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

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

Dados los últimos RFC sobre el asunto (7231 y 7235) el caso de uso parece bastante claro (cursiva añadida):

• 401 es para no autenticado ("carece de autenticación válido"); es decir, " yo no sé quién es usted, o yo no confío en usted es quien dice ser.'

401 No autorizado

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

Si la solicitud incluía credenciales de autenticación, entonces el 401 response indicates that authorization has been refused for those credencial. El agente de usuario PUEDE repetir la solicitud con un nuevo o campo de encabezado de autorización reemplazado (Sección 4.2). Si el 401 respuesta contiene el mismo desafío que la respuesta anterior, y el el agente de usuario ya ha intentado la autenticación al menos una vez, entonces el agente de usuario DEBE presentar la representación adjunta a la usuario, ya que por lo general contiene información de diagnóstico relevante.

• 403 es para no autorizado ("se niega a autorizar"); es decir, 'Sé quién eres, pero no tienes permiso para acceder a esto 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é la solicitud ha sido prohibida puede describir que razón en la carga útil de respuesta (si la hay).

Si se proporcionaron credenciales de autenticación en la solicitud, el servidor los considera insuficientes para otorgar acceso. Cliente NO debe repetir automáticamente la solicitud con el mismo credencial. El cliente PUEDE repetir la solicitud con nuevos o diferentes credencial. 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 el recurso objetivo prohibido puede responder con un código de estado de 404 (No Encontrado).

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

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

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

"Te escuché, está aquí, pero prueba esto en su lugar (no se te permite verlo)"