Qual código HTTP devo usar para uma falha de autenticação de terceiros?

Estou criando um aplicativo que possui integrações com aplicativos de terceiros.

Para fazer isso, o usuário conectado envia uma chave de API para a integração de terceiros.

No caso em que a chave de API que eles enviaram é inválida - (e retorna um 401 de terceiros), qual resposta HTTP devo retornar?

Retornar um 401 do meu aplicativo parece confuso porque, do ponto de vista do frontend, não está claro se eles não são autenticados pelo meu aplicativo ou pelo aplicativo de terceiros.

Fico tentado a fornecer apenas 400 - como se eles tivessem enviado um formulário com um endereço de e-mail inválido etc.

Se eu tivesse que escolher um código, provavelmente escolheria retornar 403 Proibido.

O RFC 7231 §6.5.3 descreve o código 403 da seguinte maneira:

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

Esse código de status é comumente usado como uma resposta genérica de 'falha na autenticação' e provavelmente não acionará nenhum mecanismo de autenticação específico, como o 401 pode obrigar um navegador a mostrar um prompt de nome de usuário / senha. O motivo específico pelo qual a autenticação falhou pode ser descrito no corpo da resposta, em um formato legível por máquina (por exemplo, JSON ou XML) ou como um documento legível por humanos (por exemplo, HTML).

O código 400 não é a pior escolha possível aqui, mas é bastante genérico.

Você pode usar o código de status HTTP code de status - 407 (autenticação de proxy necessária). De Mozilla Developers Referência :

O código de resposta do status de erro do cliente HTTP 407 Proxy Authentication Required indica que a solicitação não foi aplicada porque não possui credenciais de autenticação válidas para um servidor proxy que está entre o navegador e o servidor que pode acessar o recurso solicitado.

Seu aplicativo de back-end está agindo como um proxy para a API de terceiros; portanto, não há problema em usar 407 nesse caso.

407não está correto. Nesse caso, seu código é o proxy e é autenticado. É um sistema externo que não é autenticado.

401é razoável, mas é enganoso sobre o que não é autenticado, pois o cliente é autenticado no seu sistema. Isso também não funciona se sua autenticação estrangeira for adiada até depois de um 100Continue.

400 não está correto, pois a solicitação era válida em formato, mas a autenticação falhou no agente externo.

Todas as outras 4xxrespostas são facilmente descartadas como não aplicáveis ​​aqui.

Então, isso deixa 403Proibido, que na minha opinião é a sua única opção real neste caso:

403Proibido O cliente não tem direitos de acesso ao conteúdo; isto é, não é autorizado, portanto, o servidor se recusa a fornecer o recurso solicitado. Ao contrário de 401, a identidade do cliente é conhecida pelo servidor. Responder também com uma mensagem de status que indica "causa raiz" da falha também pode ser adequado neste caso. Realmente depende da disposição de segurança do seu aplicativo.

Meu $ .02

Eu iria com 400, ele atende ao requisito semântico. O usuário forneceu alguns dados incorretos. Como você diz, um 401/403 implica um problema entre o usuário e seu site, não seu site e algum outro aplicativo.

Seção 1 do HTTP 1.1 RFC afirma:

Introdução

Cada mensagem HTTP (Hypertext Transfer Protocol) é uma solicitação ou uma resposta. Um servidor escuta em uma conexão uma solicitação, analisa cada mensagem recebida, interpreta a semântica da mensagem em relação ao destino da solicitação identificado e responde a essa solicitação com uma ou mais mensagens de resposta. Um cliente constrói mensagens de solicitação para comunicar intenções específicas, examina as respostas recebidas para verificar se as intenções foram realizadas e determina como interpretar os resultados. Este documento define semântica de solicitação e resposta HTTP / 1.1 em termos da arquitetura definida em [RFC7230].

Portanto, a definição dos códigos de status está entre um cliente e um servidor. Para mim, isso significa escolher aquele que faz mais sentido para outras interações (servidor para servidor, back-end, etc.).

Todos os outros exóticos oferecidos aqui vão confundir o consumidor do serviço.

É sempre bom enviar 403

mas, se necessário, você pode adicionar informações sobre o json

[Serializable]
[DataContract]
class Response
{
    [DataMember]
    public bool IsSuccess { get; set; }
    [DataMember]
    public string Message { get; set; }
    [DataMember]
    public object ResponseData { get; set; }

    public Response(bool status, string message, object data)
    {
        IsSuccess = status;
        Message = message;
        ResponseData = data;
    }
}

E então, na resposta, adicione também as seguintes informações

 return Json(new Response(false, "Login Failed, The user name or password provided is incorrect.", null));

quando uma solicitação é feita, você pode desativar o botão de login - e somente quando uma atualização é feita, o botão pode ser ativado - lógica do lado do cliente.

Os 424 - Failed Dependencyfatos muito bem neste caso.

O código de status 424 (Failed Dependency) significa que o método não pôde ser executado no recurso porque a ação solicitada dependia de outra ação e a ação falhou.

Vou me inclinar para 407. 407 Autenticação de proxy necessária Este código é semelhante ao 401 (Não autorizado), mas indica que o cliente deve primeiro se autenticar com o proxy. O proxy DEVE retornar um campo de cabeçalho Proxy-Authenticate (seção 14.33) contendo um desafio aplicável ao proxy para o recurso solicitado. O cliente PODE repetir o pedido com um campo de cabeçalho de Proxy-Authorization adequado (seção 14.34). A autenticação de acesso HTTP é explicada em "Autenticação HTTP: Autenticação de Acesso Básico e Digest".como Iskander mencionou.

Ele indica melhor o usuário sobre qual poderia ser o problema. Além disso, você pode avançar e implementar o cabeçalho de autorização de proxy para ser totalmente consistente com as especificações.

Usar 400 faria seu cliente coçar a cabeça, procurando o que ele estava fazendo de errado ao criar a solicitação.

Usar 401 ou 403 faz mais sentido mantê-los para sua própria autenticação e autorização de API.

502 indica ao usuário que o problema está ocorrendo a montante, para que ele possa ficar pendurado até que você o resolva.

Eu ficaria com 401. O erro 401 não autorizado é um código de status HTTP que significa que a página que o usuário estava tentando acessar não pode ser carregada até que o usuário efetue login com um ID de usuário e senha válidos. Se o usuário acabou de fazer login e recebeu o erro 401 Não autorizado, significa que as credenciais inseridas pelo usuário foram inválidas por algum motivo. No nosso caso, a chave da API que eles enviaram era inválida. Existe um diagrama de atividades que eu estava usando quando tenho uma confusão com os códigos de erro.

Aqui abaixo está o link para o mesmo:

https://i.stack.imgur.com/ppsbq.jpg

Nesse caso, o servidor intermediário foi registrado com êxito e o servidor upstream se recusa a realizar a autenticação em virtude da chave inválida. Parece que o código 502 (Bad Gateway) se encaixa nessa situação, pois esse código representa um servidor que atua como um gateway (Seu) e está recebendo uma resposta inválida do servidor upstream (terceiros).