Ver RFC2616:

401 não autorizado:

Se o pedido já incluía credenciais de autorização, então a resposta 401 indica que a autorização foi recusada para essas credenciais.

403 Proibido:

O servidor compreendeu o pedido, mas recusa-se a cumpri-lo.

Actualizar

No seu caso de Utilização, parece que o utilizador não está autenticado. Eu voltaria. 401.

Edit: RFC2616 é obsoleto, consulte RFC7231 e RFC7235.

Algo que as outras respostas estão faltando é que deve ser entendido que autenticação e autorização no contexto do RFC 2616 se refere apenas ao protocolo de autenticação HTTP do RFC 2617. Autenticação por esquemas fora do RFC2617 não são suportados em códigos de estado HTTP e não são considerados ao decidir se usar 401 ou 403..

Breve e profundo

Não autorizado indica que o cliente não está autenticado e o servidor está a iniciar o processo de autenticação. O Forbidden indica que o cliente está autenticado e não tem autorização ou que o servidor não suporta o rfc2617 para o recurso solicitado.

O que significa que se tiver o seu próprio processo de autenticação e nunca usar a autenticação HTTP, o 403 é sempre a resposta adequada e o 401 nunca deve ser usado.

Detalhado e em profundidade

De RFC2616

10.4.2 401 não autorizado

O pedido necessita de autenticação do utilizador. A resposta deve incluir um campo de cabeçalho WWW-autenticar (secção 14.47) contendo um desafio aplicável ao recurso solicitado. O cliente pode repetir o pedido com um cabeçalho de autorização adequado (ponto 14.8).

E

10.4.4 403 Proibido O servidor entendeu o pedido, mas se recusa a cumpri-lo. A autorização não ajudará e o pedido não deve ser repetido.

Então a diferença real não é o que o problema é ou mesmo se há uma solução. A diferença é o que o servidor espera o cliente a seguir.

401 indica que o recurso não pode ser fornecido, mas o servidor está a pedir que o cliente faça login através da autenticação HTTP e enviou cabeçalhos de resposta para iniciar o processo. Possivelmente existem autorizações que permitirão o acesso ao recurso, possivelmente não existem, mas vamos dar-lhe uma tentativa e ver o que acontece.

403 indica que o recurso não pode ser fornecido e que, para o utilizador actual, não existe forma de resolver isto através do RFC2617 e não vale a pena tentar. Isto pode ser porque se sabe que nenhum nível de autenticação é suficiente (por exemplo, por causa de uma lista negra IP), mas pode ser porque o usuário já está autenticado e não tem autoridade. O modelo RFC2617 é um usuário, uma-credenciais de modo que o caso em que o usuário pode ter um segundo conjunto de credenciais que poderia ser autorizado pode ser ignorado. Ele não sugere nem implica que algum tipo de página de login ou outro protocolo de autenticação não-RFC2617 pode ou pode não ajuda - isso está fora dos padrões e definição RFC2616.

Edit: RFC2616 é obsoleto, consulte RFC7231 e RFC7235.

De acordo com RFC 2616 (HTTP/1. 1) 403 é enviado quando:

O servidor compreendeu o pedido, mas recusa-se a cumpri-lo. A autorização não ajudará e o pedido não deve ser repetido. Se o método de solicitação não foi HEAD e o servidor deseja tornar público por que o pedido não foi cumprido, ele deve descrever a razão para a recusa na entidade. Se o servidor não deseja disponibilizar esta informação ao cliente, o código de Estado 404 (Não encontrado) pode ser usado em vez de

Por outras palavras, se o cliente pode ter acesso ao recurso autenticando, 401 deve ser enviado.

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

Os controlos são normalmente efectuados por esta ordem:

• 401 se a sessão não expirou
• 403 se o utilizador não tiver permissão para aceder ao recurso
• 404 se o recurso não existir

Não autorizado : Código de Estado (401), indicando que o pedido necessita de autenticação, normalmente isto significa que o utilizador precisa de estar ligado (sessão). Utilizador / agente desconhecido pelo servidor. Pode repetir com outras credenciais. Nota: Isto é confuso como isto deveria ter sido nomeado "não autenticado" em vez de "não autorizado". Isto também pode falhar se a sessão expirou.

FORBIDDEN : Código de Estado (403) indicando que o servidor entendeu o pedido, mas recusou-se a cumpri-lo. Utilizador / agente conhecido pelo servidor mas tem credenciais insuficientes . O pedido repetido não funcionará, a menos que as credenciais mudem, o que é muito improvável em um curto espaço de tempo.

Não foi encontrado : Código de Estado (404), indicando que o o recurso pedido não está disponível. Usuário / agente conhecido mas servidor não vai revelar nada sobre o recurso, faz como se ele não existe. Repetir não vai funcionar. Este é um uso especial de 404 (github faz isso por exemplo).

Se a autenticação como outro utilizador permitir o acesso ao recurso solicitado, então 401 não autorizado deve ser devolvido. 403 Proibido é usado principalmente quando o acesso ao recurso é proibido para todos, ou restrita a uma determinada rede ou permitidas somente através de SSL, o que quer desde que não relacionados à autenticação.

Da RFC 7235 (Protocolo de transferência de hipertexto (HTTP / 1.1): autenticação):

3.1. 401 não autorizado

O 401 (Não Autorizado) o código do estado indica que o pedido tem não foi aplicado porque não tem credenciais de autenticação válidas para o recurso alvo. O servidor de origem deve enviar um Campo de cabeçalho WWW-autenticar (Secção 4. 4) contendo pelo menos um desafio aplicável ao recurso-alvo. Se o pedido incluindo credenciais de autenticação, em seguida, a resposta 401 indica que a autorização foi recusada para os credenciais O cliente pode repetir a pedido com um novo ou campo de cabeçalho da autorização substituído (Secção 4.1). Se o 401 a resposta contém o mesmo desafio que a resposta anterior, e o agente do utilizador já tentou a autenticação pelo menos uma vez, depois o agente de Utilizador deverá apresentar a representação em anexo ao utilizador, uma vez que normalmente contém informação de diagnóstico relevante.

E isto é da RFC 2616:

10.4.4 403 Proibido

O servidor entendeu o pedido, mas recusa-se a cumpri-lo.
a autorização não ajudará e o pedido não deve ser repetido.
Se o método de requisição não foi o HEAD e o servidor deseja fazer
público por que o pedido não foi satisfeito, deve descrever o motivo da recusa na entidade. Se o servidor não desejar coloque esta informação à disposição do cliente, o código de Estado 404
(Não encontrado) pode ser usado em vez disso.

Editar: RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1): semantics and Content) changes the meaning of 403:

6.5.3. 403 Proibido

O código de Estado 403 (Proibido) indica que o servidor entendido o pedido, mas recusa-se a autorizá-lo. Um servidor que desejo tornar público o motivo pelo qual o pedido foi proibido pode descrever essa razão na carga útil de resposta (se existir).

Se as credenciais de autenticação foram fornecidas no pedido, o
o servidor considera-os insuficientes para conceder acesso. O cliente
Não deve repetir automaticamente o pedido com o mesmo
credencial. O cliente pode repetir o pedido com novo ou diferente credencial. No entanto, um pedido pode ser proibido por razões
sem relação com as credenciais.

Um servidor de origem que deseja "esconder" a existência actual de um
o recurso alvo proibido poderá responder com um código de Estado de
404 (Não aplicável) Encontrado).

O OWASP tem mais informaçõessobre como um atacante pode usar este tipo de informação como parte de um ataque.

A secção 6.5.3 neste rascunho (de autoria de Fielding e Reschke) dá ao código de Estado 403 um significado ligeiramente diferente do documentado em RFC 2616.

Reflecte o que acontece nos sistemas de autenticação e autorização utilizados por vários servidores e quadros web populares.

6.5.3. 403 Proibido

O código de Estado 403 (Proibido) indica que o servidor entendeu o pedido, mas se recusa a autorizá-lo. Um servidor que deseja tornar público por que o pedido foi proibido pode descrever essa razão na resposta payload (se houver).

Se as credenciais de autenticação foram fornecidas no pedido, o servidor considera-as insuficientes para conceder acesso. o cliente não deve repetir o pedido com as mesmas credenciais. O o cliente pode repetir o pedido com credenciais novas ou diferentes. no entanto, um pedido pode ser proibido por razões não relacionadas com as credenciais.

Um servidor de origem que deseja "esconder" a existência actual de um recurso de destino proibido pode responder com um código de Estado de 404 (não encontrado).

Seja qual for a convenção que use, o importante é assegurar uniformidade no seu site / API.

TL; DR

• 401: uma recusa que tem A ver com autenticação
• 403: uma recusa que não tem nada a ver com autenticação

Exemplos Práticos

Se apache necessita de autenticação (via .htaccess), e se carregar em Cancel, irá responder com um 401 Authorization Required

Se nginx encontrar um ficheiro, mas não tiver direitos de acesso (utilizador/grupo) para o ler / aceder, irá responder com 403 Forbidden

RFC (secção 2616 10)

Significa 1: preciso de autenticar

O pedido requer autenticação do utilizador. ...

Significa 2: autenticação insuficiente

... Se o pedido já incluía credenciais de autorização, então a resposta 401 indica que a autorização foi recusada para essas credenciais. ...

403 Proibido (10.4.4)

Significa: Sem Relação à autenticação

... A autorização não vai ajudar ...

mais detalhes:

• O servidor compreendeu o pedido, mas recusa-se a cumpri-lo.

• Deve descrever o motivo da recusa na entidade

• O código de Estado 404 (não encontrado) pode ser usado em vez de

  (Se o servidor quiser manter esta informação de cliente)

Eles não estão logados ou não pertencem ao grupo de utilizadores apropriado

Indicou dois casos diferentes; cada caso deve ter uma resposta diferente:

1. se eles não estão conectados, você deve retornar 401 não autorizado
2. se eles estão logados mas não pertencem ao grupo de utilizadores adequado, você deve retornar 403 Proibido

Acho que é importante considerar que, para um navegador, o 401 inicia uma janela de autenticação para o Utilizador introduzir novas credenciais, enquanto o 403 não. Os navegadores pensam que, se um 401 for devolvido, então o Usuário deve re-autenticar. Então 401 significa autenticação inválida enquanto 403 significa falta de permissão.

Aqui estão alguns casos sob essa lógica onde um erro seria devolvido da autenticação ou autorização, com frases importantes negro.

• um recurso necessita de autenticação, mas nenhuma credenciais foi especificado .

401: o cliente deve especificar as credenciais.

• as credenciais indicadas estão num formato inválido.

400: isso não é 401 nem 403, pois os erros de sintaxe devem sempre retornar 400.

• as credenciais especificadas referem a utilizador que não existe

401: o cliente deve especificar credenciais válidas.

• as credenciais indicadas são inválidas mas indica um utilizador válido (ou não indica um utilizador como um utilizador indicado não é necessário).

401: Mais uma vez, o cliente deve especificar credenciais válidas.

• as credenciais especificadas têm expirado .

401: isto é praticamente o mesmo que ter inválido credenciais em geral, para que o cliente deve especificar credenciais válidas.

• as credenciais especificadas são completamente válidas mas não são suficientes {[8] } o recurso em particular , embora seja possível que as credenciais com mais Permissão possam.

403: especificar credenciais válidas não permitiria o acesso ao recurso, uma vez que as credenciais atuais já são válidas, mas apenas não têm permissão.

• o recurso específico é inacessível independentemente das credenciais.

403: isto é independente de credenciais, então especificar credenciais válidas não pode ajudar.

• as credenciais especificadas são completamente válidas mas o cliente em particular é bloqueado de As usar.

403: Se o cliente estiver bloqueado, especificar novas credenciais não fará nada.

401: você precisa da Autenticação Básica de HTTP para ver isto.

403: você não pode ver isso, e o HTTP basic auth não vai ajudar.

Se o utilizador apenas precisar de fazer login usando o formulário de login HTML padrão do seu site, o 401 não seria apropriado porque é específico do HTTP basic auth.

Em outras palavras, 403 significa "este recurso requer alguma forma de auth que não o HTTP basic auth".

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

Dado mais recente do RFC sobre o assunto (7231 e 7235) o caso de uso, parece bastante claro (grifo do autor):

• 401 is for unauthenticated ("falta autenticação válida"); i.e. 'I don't know who you are, or I don't trust you are who you say you are.'

401 não autorizado

O código de Estado 401 (não autorizado) indica que o pedido não foi aplicado porque carece de validade autenticação credenciais para o recurso alvo. O servidor que gera uma resposta 401 deve enviar um campo de cabeçalho WWW-autenticar (Secção 4.1) contendo pelo menos um desafio aplicável ao recurso-alvo.

Se o pedido incluía credenciais de autenticação, então o 401 a resposta indica que a autorização foi recusada para os credencial. O agente de utilizador pode repetir o pedido com um novo ou cabeçalho da autorização substituído (Secção 4.2). Se o 401 a resposta contém o mesmo desafio que a resposta anterior, e o agente do utilizador já tentou a autenticação pelo menos uma vez, depois o agente de Utilizador deverá apresentar a representação em anexo ao utilizador, uma vez que normalmente contém informação de diagnóstico relevante.

• 403 é para não autorizado ("recusa autorizar"); ou seja, 'eu sei quem você é, mas você não tem permissão para acessar este recurso.'

403 Proibido

O código de Estado 403 (Proibido) indica que o servidor compreendeu o pedido, mas recusa-se a autorizá-lo. Um servidor que deseja tornar público por que o pedido foi proibido pode descrever que razão na carga útil de resposta (se existir).

Se as credenciais de autenticação foram fornecidas no pedido, o o servidor considera-os insuficientes para conceder acesso. Cliente Não deve repetir automaticamente o pedido com o mesmo credencial. O cliente pode repetir o pedido com novo ou diferente credencial. No entanto, um pedido pode ser proibido por razões sem relação com as credenciais.

Um servidor de origem que deseja "esconder" a existência actual de um o recurso de destino proibido poderá responder com um código de Estado de 404 (Não Encontrado).

No caso de 401 vs 403, isto foi respondido muitas vezes. Este é essencialmente um debate "HTTP request environment", não um debate "application".

Parece haver uma questão no role-your-o-próprio-login issue (application).

Neste caso, simplesmente não estar ligado não é suficiente para enviar um 401 ou um 403, a menos que você use HTTP Auth vs uma página de autenticação (não ligado à Configuração HTTP Auth). Parece que você pode estar procurando um "201 Criado" , com um roll-your-o-próprio-login screen present (instead of the requested resource) for the application-level access to a file. Isto diz:

" Eu ouvi-te, está aqui, mas tenta isto em vez disso (não estás autorizado a vê-lo)"