Para uma página da Web que existe, mas para a qual um usuário não possui privilégios suficientes (não está logado ou não pertence ao grupo de usuários adequado), qual é a resposta HTTP correta a ser veiculada?

401 Unauthorized?
403 Forbidden?
Algo mais?

O que eu li em cada um até agora não está muito claro sobre a diferença entre os dois. Quais casos de uso são apropriados para cada resposta?

Uma explicação clara de Daniel Irvine :

Há um problema com o 401 Não autorizado , o código de status HTTP para erros de autenticação. E é isso: é para autenticação, não para autorização. Receber uma resposta 401 é o servidor dizendo: "você não está autenticado - ou não está autenticado de maneira alguma ou autenticado incorretamente - mas por favor, autentique novamente e tente novamente". Para ajudá-lo, sempre incluirá um cabeçalho WWW-Authenticate que descreve como se autenticar.

Essa é uma resposta geralmente retornada pelo servidor da web, não pelo aplicativo da web.

Também é algo muito temporário; o servidor está pedindo para você tentar novamente.

Portanto, para autorização, uso a resposta 403 Proibida . É permanente, está vinculado à minha lógica de aplicativo e é uma resposta mais concreta do que uma 401.

Receber uma resposta 403 é o servidor dizendo: “Sinto muito. Eu sei quem você é - acredito que você diz que é - mas você simplesmente não tem permissão para acessar este recurso. Talvez se você perguntar bem ao administrador do sistema, obterá permissão. Mas por favor não me incomode novamente até que sua situação mude.

Em resumo, uma resposta 401 Não Autorizada deve ser usada para autenticação ausente ou incorreta, e uma resposta 403 Proibida deve ser usada posteriormente, quando o usuário for autenticado, mas não estiver autorizado a executar a operação solicitada no recurso fornecido.

Outro bom formato pictórico de como os códigos de status http devem ser usados.

Veja RFC2616 :

401 não autorizado:

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

403 Proibido:

O servidor entendeu a solicitação, mas está se recusando a atendê-la.

Atualizar

No seu caso de uso, parece que o usuário não está autenticado. Eu voltaria 401.

Edit: RFC2616 é obsoleto, consulte RFC7231 e RFC7235 .

Algo que falta outras respostas é que deve ser entendido que Autenticação e Autorização no contexto da RFC 2616 se refere SOMENTE ao protocolo de Autenticação HTTP da RFC 2617. A autenticação por esquemas fora da RFC2617 não é suportada nos códigos de status HTTP e não é considerada ao decidir usar 401 ou 403.

Breve e conciso

Não autorizado indica que o cliente não está autenticado pelo RFC2617 e o servidor está iniciando o processo de autenticação. Proibido indica que o cliente está autenticado pelo RFC2617 e não tem autorização ou que o servidor não oferece suporte ao RFC2617 para o recurso solicitado.

Ou seja, se você possui seu próprio processo de login do tipo roll-your-own e nunca usa a autenticação HTTP, 403 é sempre a resposta adequada e 401 nunca deve ser usado.

Detalhado e Detalhado

From RFC2616

10.4.2 401 Não autorizado

A solicitação requer autenticação do usuário. A resposta DEVE incluir um campo de cabeçalho WWW-Authenticate (seção 14.47) contendo um desafio aplicável ao recurso solicitado. O cliente pode repetir o pedido com um campo de cabeçalho de autorização adequado (seção 14.8).

e

10.4.4 403 Proibido O servidor entendeu a solicitação, mas está se recusando a atendê-la. A autorização não ajudará e a solicitação NÃO DEVE ser repetida.

A primeira coisa a ter em mente é que "Autenticação" e "Autorização", no contexto deste documento, se referem especificamente aos protocolos de Autenticação HTTP do RFC 2617. Eles não se referem a nenhum protocolo de autenticação de rolagem que você possa ter criado usando páginas de login, etc. Usarei "login" para me referir à autenticação e autorização por outros métodos que não o RFC2617

Portanto, a verdadeira diferença não é qual é o problema ou mesmo se existe uma solução. A diferença é o que o servidor espera que o cliente faça a seguir.

401 indica que o recurso não pode ser fornecido, mas o servidor SOLICITA que o cliente efetue 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, mas vamos tentar e ver o que acontece.

403 indica que o recurso não pode ser fornecido e, para o usuário atual, não há como resolver isso através do RFC2617 e não há motivo para tentar. Isso pode ser porque se sabe que nenhum nível de autenticação é suficiente (por exemplo, devido a uma lista negra de IP), mas pode ser porque o usuário já está autenticado e não possui autoridade. O modelo RFC2617 é de um usuário e uma credencial; portanto, o caso em que o usuário pode ter um segundo conjunto de credenciais que podem ser autorizadas pode ser ignorado. Ele não sugere nem implica que algum tipo de página de login ou outro protocolo de autenticação que não seja RFC2617 pode ou não ajudar - isso está fora dos padrões e da definição RFC2616.

Edit: RFC2616 é obsoleto, consulte RFC7231 e RFC7235 .

  + -----------------------
  | EXISTE RECURSO? (se privado, geralmente é verificado APÓS a verificação de autenticação)
  + -----------------------
    | |
 NÃO v SIM
    v + -----------------------
   404 Está logado? (autenticado, também conhecido como cookie de sessão ou JWT)
   ou + -----------------------
   401 |
   403 NÃO | SIM
   3xx vv
              401 + -----------------------
       (404 sem revelação) | PODE ACESSAR RECURSOS? (permissão, autorizada, ...)
              ou + -----------------------
             redirecionar | |
             entrar NO | | SIM
                               | |
                               vv
                               403 OK 200, redirecionar, ...
                      (ou 404: sem revelação)
                      (ou 404: o recurso não existe se privado)
                      (ou 3xx: redirecionamento)

As verificações geralmente são feitas nesta ordem:

• 404 se o recurso for público e não existir ou redirecionamento 3xx
• DE OUTRA FORMA:
• 401 se não estiver logado ou a sessão expirou
• 403 se o usuário não tiver permissão para acessar o recurso (arquivo, json, ...)
• 404 se o recurso não existir ou não estiver disposto a revelar nada ou o redirecionamento 3xx

NÃO AUTORIZADO : Código de status (401) indicando que a solicitação requer autenticação , geralmente isso significa que o usuário precisa estar conectado (sessão). Usuário / agente desconhecido pelo servidor. Pode repetir com outras credenciais. NOTA: Isso é confuso, pois deveria ter sido nomeado 'não autenticado' em vez de 'não autorizado'. Isso também pode acontecer após o login, se a sessão expirou. Caso especial: pode ser usado em vez de 404 para evitar a presença ou a não presença de recursos (créditos @gingerCodeNinja)

PROIBIDO : O código de status (403) indicando que o servidor entendeu a solicitação, mas se recusou a atendê-la. Usuário / agente conhecido pelo servidor, mas não possui credenciais suficientes . A solicitação repetida não funcionará, a menos que as credenciais sejam alteradas, o que é muito improvável em um curto espaço de tempo. Caso especial: pode ser usado em vez de 404 para evitar a presença ou a não presença de recursos (créditos @gingerCodeNinja)

NÃO ENCONTRADO : Código de status (404) indicando que o recurso solicitado não está disponível. Usuário / agente conhecido, mas o servidor não revelará nada sobre o recurso, faz como se ele não existisse. Repetir não funcionará. Este é um uso especial do 404 (o github faz isso por exemplo).

Como mencionado por @ChrisH, existem algumas opções para o redirecionamento 3xx (301, 302, 303, 307 ou não redirecionar de forma alguma e usar um 401):

• Diferença entre códigos de redirecionamento HTTP
• Por quanto tempo os navegadores armazenam em cache o HTTP 301s?
• O que é o código de status HTTP correto ao redirecionar para uma página de login?
• Qual é a diferença entre um redirecionamento 302 e um 307?

De acordo com a RFC 2616 (HTTP / 1.1) 403 é enviado quando:

O servidor entendeu a solicitação, mas está se recusando a atendê-la. A autorização não ajudará e a solicitação NÃO DEVE ser repetida. Se o método de solicitação não foi HEAD e o servidor deseja tornar público o motivo pelo qual a solicitação não foi atendida, DEVE descrever o motivo da recusa na entidade. Se o servidor não desejar disponibilizar essas informações ao cliente, o código de status 404 (Não encontrado) poderá ser usado.

Em outras palavras, se o cliente puder acessar o recurso autenticando, o 401 deverá ser enviado.

Supondo que a autenticação HTTP ( cabeçalhos WWW-Authenticate and Authorization ) esteja em uso , se a autenticação como outro usuário conceder acesso ao recurso solicitado, 401 401 não autorizado deve ser retornado.

403 Proibido é usado quando o acesso ao recurso é proibido a todos ou restrito a uma determinada rede ou permitido apenas por SSL, desde que não relacionado à autenticação HTTP.

Se a autenticação HTTP não estiver em uso e o serviço for um esquema de autenticação baseado em cookie, como é a norma atualmente, um 403 ou 404 deve ser retornado.

Em relação ao 401, este é do RFC 7235 (Protocolo de Transferência de Hipertexto (HTTP / 1.1): Autenticação):

3.1 401 não autorizado

O código de status 401 (não autorizado) indica que a solicitação não foi aplicada porque não possui credenciais de autenticação válidas para o recurso de destino. O servidor de origem DEVE enviar um campo de cabeçalho WWW-Authenticate (Seção 4.4) contendo pelo menos um desafio aplicável ao recurso de destino. Se a solicitação incluir credenciais de autenticação, a resposta 401 indicará que a autorização foi recusada para essas credenciais. O cliente PODE repetir o pedido com um campo de cabeçalho de Autorização novo ou substituído (Seção 4.1). Se a resposta 401 contém o mesmo desafio que a resposta anterior, e o agente do usuário já tentou a autenticação pelo menos uma vez, o agente do usuário DEVE apresentar a representação em anexo ao usuário, pois geralmente contém informações de diagnóstico relevantes.

A semântica de 403 (e 404) mudou ao longo do tempo. Isso é de 1999 (RFC 2616):

10.4.4 403 Proibido

O servidor entendeu a solicitação, mas está se recusando a atendê-la.
A autorização não ajudará e a solicitação NÃO DEVE ser repetida.
Se o método de solicitação não foi HEAD e o servidor deseja tornar
público o motivo pelo qual a solicitação não foi atendida, DEVE descrever o motivo da recusa na entidade. Se o servidor não desejar disponibilizar essas informações ao cliente, o código de status 404
(Não encontrado) poderá ser usado.

Em 2014, o RFC 7231 (Protocolo de transferência de hipertexto (HTTP / 1.1): Semântica e conteúdo) mudou o significado de 403:

6.5.3 403 Proibido

O código de status 403 (Proibido) indica que o servidor entendeu a solicitação, mas se recusa a autorizá-la. Um servidor que deseja tornar público o motivo pelo qual a solicitação foi proibida pode descrever esse motivo na carga útil da resposta (se houver).

Se credenciais de autenticação foram fornecidas na solicitação, o
servidor as considera insuficientes para conceder acesso. O cliente
não deve repetir automaticamente o pedido com as mesmas
credenciais. O cliente pode repetir o pedido com credenciais novas ou diferentes. No entanto, uma solicitação pode ser proibida por motivos
não relacionados às credenciais.

Um servidor de origem que deseja "ocultar" a existência atual de um
recurso de destino proibido PODE responder com um código de status
404 (Não encontrado).

Assim, um 403 (ou um 404) agora pode significar qualquer coisa. O fornecimento de novas credenciais pode ajudar ... ou não.

Acredito que a razão pela qual isso mudou foi o RFC 2616, assumido que a autenticação HTTP seria usada quando, na prática, os aplicativos Web de hoje criam esquemas de autenticação personalizados usando, por exemplo, formulários e cookies.

Essa é uma pergunta antiga, mas uma opção que nunca foi realmente apresentada foi retornar um 404. Do ponto de vista da segurança, a resposta mais votada sofre com uma potencial vulnerabilidade de vazamento de informações . Digamos, por exemplo, que a página da web segura em questão seja uma página de administração do sistema, ou talvez mais comumente, seja um registro em um sistema ao qual o usuário não tenha acesso. Idealmente, você não gostaria que um usuário mal-intencionado soubesse que há uma página / registro lá, muito menos que ele não tem acesso. Quando estiver criando algo parecido com isto, tentarei registrar solicitações não autenticadas / não autorizadas em um log interno, mas retornarei um 404.

O OWASP tem mais algumas informações sobre como um invasor pode usar esse tipo de informação como parte de um ataque.

• 401 Não autorizado : Não sei quem você é. Este é um erro de autenticação.
• 403 Proibido : Eu sei quem você é, mas você não tem permissão para acessar este recurso. Este é um erro de autorização.

Esta pergunta foi feita há algum tempo, mas o pensamento das pessoas segue em frente.

A Seção 6.5.3 neste rascunho (de autoria de Fielding e Reschke) atribui ao código de status 403 um significado ligeiramente diferente daquele documentado na RFC 2616 .

Ele reflete o que acontece nos esquemas de autenticação e autorização empregados por vários servidores e estruturas da Web populares.

Eu enfatizei o que acho mais saliente.

6.5.3 403 Proibido

O código de status 403 (Proibido) indica que o servidor entendeu a solicitação, mas se recusa a autorizá-la. Um servidor que deseja tornar público o motivo pelo qual a solicitação foi proibida pode descrever esse motivo na carga útil da resposta (se houver).

Se credenciais de autenticação foram fornecidas na solicitação, o servidor as considera insuficientes para conceder acesso. O cliente não deve repetir o pedido com as mesmas credenciais. O cliente pode repetir o pedido com credenciais novas ou diferentes. No entanto, uma solicitação pode ser proibida por motivos não relacionados às credenciais.

Um servidor de origem que deseja "ocultar" a existência atual de um recurso de destino proibido PODE responder com um código de status 404 (Não encontrado).

Qualquer que seja a convenção usada, o importante é fornecer uniformidade em todo o site / API.

TL; DR

• 401: Uma recusa relacionada à autenticação
• 403: Uma recusa que nada tem a ver com autenticação

Exemplos práticos

Se o apache exigir autenticação (via .htaccess) e você clicar Cancel, ele responderá com um401 Authorization Required

Se o nginx encontrar um arquivo, mas não tiver direitos de acesso (usuário / grupo) para lê-lo / acessá-lo, ele responderá com403 Forbidden

RFC (2616 Seção 10)

401 Não autorizado (10.4.2)

Significado 1: Necessidade de autenticação

A solicitação requer autenticação do usuário. ...

Significado 2: Autenticação insuficiente

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

403 Proibido (10.4.4)

Significado: Não relacionado à autenticação

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

Mais detalhes:

• O servidor entendeu a solicitação, mas está se recusando a atendê-la.

• DEVE descrever o motivo da recusa na entidade

• O código de status 404 (Não encontrado) pode ser usado

  (Se o servidor quiser manter essas informações do cliente)

eles não estão conectados ou não pertencem ao grupo de usuários apropriado

Você declarou dois casos diferentes; cada caso deve ter uma resposta diferente:

1. Se eles não estiverem conectados, você deve devolver 401 Não Autorizado
2. Se eles estiverem conectados, mas não pertencerem ao grupo de usuários adequado, você deverá retornar 403 Proibido

Nota sobre a RFC com base nos comentários recebidos para esta resposta:

Se o usuário não estiver logado, ele não será autenticado, cujo equivalente HTTP é 401 e é enganosamente chamado de Não autorizado no RFC. Conforme a seção 10.4.2 afirma para 401 Não autorizado :

"A solicitação requer autenticação do usuário ."

Se você não for autenticado, 401 é a resposta correta. No entanto, se você não for autorizado, no sentido semanticamente correto, 403 é a resposta correta.

Estes são os significados:

401 : Usuário não autenticado (corretamente), o recurso / página requer autenticação

403 : Usuário autenticado, mas sua função ou permissões não permitem acessar o recurso solicitado, por exemplo, o usuário não é um administrador e a página solicitada é para administradores

Isso é mais simples na minha cabeça do que em qualquer lugar aqui, então:

401: Você precisa de autenticação básica HTTP para ver isso.

403: Você não pode ver isso, e a autenticação básica HTTP não ajudará.

Se o usuário precisar fazer login usando o formulário de login HTML padrão do seu site, 401 não seria apropriado porque é específico para a autenticação básica HTTP.

Não recomendo usar 403 para negar acesso a coisas como /includes , porque, no que diz respeito à web, esses recursos não existem e, portanto, devem ser 404.

Isso deixa 403 como "você precisa estar logado".

Em outras palavras, 403 significa "esse recurso requer alguma forma de autenticação diferente da autenticação básica HTTP".

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

Eu acho que é importante considerar que, para um navegador, o 401 inicia uma caixa de diálogo de autenticação para o usuário inserir novas credenciais, enquanto o 403 não. Os navegadores pensam que, se um 401 for retornado, o usuário deverá se autenticar novamente. Então 401 significa autenticação inválida, enquanto 403 significa falta de permissão.

Aqui estão alguns casos sob essa lógica em que um erro seria retornado da autenticação ou autorização, com frases importantes em negrito.

• Um recurso requer autenticação, mas nenhuma credencial foi especificada .

401 : O cliente deve especificar credenciais.

• As credenciais especificadas estão em um formato inválido .

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

• As credenciais especificadas referenciam um usuário que não existe .

401 : O cliente deve especificar credenciais válidas.

• As credenciais especificadas são inválidas, mas especificam um usuário válido (ou não especifique um usuário se um usuário especificado não for necessário).

401 : Novamente, o cliente deve especificar credenciais válidas.

• Os especificadas credenciais ter expirado .

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

• As credenciais especificadas são completamente válidas, mas não são suficientes para o recurso específico , embora seja possível que credenciais com mais permissão possam.

403 : A especificação de credenciais válidas não concederia acesso ao recurso, pois as credenciais atuais já são válidas, mas apenas não têm permissão.

• O recurso específico está inacessível, independentemente das credenciais.

403 : Isso independentemente das credenciais, portanto, especificar credenciais válidas não pode ajudar.

• As credenciais especificadas são completamente válidas, mas o cliente específico está impedido de usá-las.

403 : Se o cliente estiver bloqueado, a especificação de novas credenciais não fará nada.

Em inglês:

401

Você tem acesso potencialmente permitido, mas, por algum motivo, nesta solicitação, foi negado. Como uma senha incorreta? Tente novamente, com a solicitação correta, você receberá uma resposta bem-sucedida.

403

Você nunca é permitido. Seu nome não está na lista, você nunca entrará, sairá, não enviará uma solicitação de nova tentativa, ela será recusada, sempre. Vá embora.

Dadas as últimas RFCs sobre o assunto ( 7231 e 7235 ), o caso de uso parece bastante claro (itálico adicionado):

• 401 é para não autenticado ("não possui autenticação válida"); ou seja, 'Eu não sei quem você é, ou não confio em que você é quem diz ser'.

401 não autorizado

O código de status 401 (não autorizado) indica que a solicitação não foi aplicada porque não possui autenticação válida credenciais de para o recurso de destino. O servidor que gera uma resposta 401 DEVE enviar um campo de cabeçalho WWW-Authenticate (Seção 4.1) contendo pelo menos um desafio aplicável ao recurso de destino.

Se a solicitação incluísse credenciais de autenticação, a resposta 401 indica que a autorização foi recusada para essas credenciais. O agente do usuário PODE repetir a solicitação com um campo de cabeçalho de Autorização novo ou substituído (Seção 4.2). Se a resposta 401 contém o mesmo desafio que a resposta anterior, e o agente do usuário já tentou a autenticação pelo menos uma vez, o agente do usuário DEVE apresentar a representação em anexo ao usuário, pois geralmente contém informações de diagnóstico relevantes.

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

403 Proibido

O código de status 403 (Proibido) indica que o servidor entendeu a solicitação, mas se recusa a autorizá- la. Um servidor que deseja tornar público o motivo pelo qual a solicitação foi proibida pode descrever esse motivo na carga útil da resposta (se houver).

Se credenciais de autenticação foram fornecidas na solicitação, o servidor as considera insuficientes para conceder acesso. O cliente não deve repetir automaticamente o pedido com as mesmas credenciais. O cliente pode repetir o pedido com credenciais novas ou diferentes. No entanto, uma solicitação pode ser proibida por motivos não relacionados às credenciais.

Um servidor de origem que deseja "ocultar" a existência atual de um recurso de destino proibido PODE responder com um código de status 404 (Não encontrado).

No caso de 401 vs 403, isso foi respondido muitas vezes. Este é essencialmente um debate sobre o 'ambiente de solicitação HTTP', não um debate sobre 'aplicativo'.

Parece haver uma pergunta sobre o problema de rolar o seu próprio login (aplicativo).

Nesse caso, simplesmente não fazer login não é suficiente para enviar um 401 ou um 403, a menos que você use HTTP Auth x uma página de login (não vinculada à configuração do HTTP Auth). Parece que você pode estar procurando um "201 Criado", com uma tela de login do tipo roll-your-own-presente (em vez do recurso solicitado) para o acesso no nível do aplicativo a um arquivo. Isto diz:

"Eu ouvi você, está aqui, mas tente fazer isso (você não tem permissão para vê-lo)"