Oauthlib: Status HTTP inválido na resposta de erro

A especificação menciona que 401 pode ser usado com erros de cliente inválidos e deve ser usado quando a autenticação foi feita através do campo de cabeçalho de autorização. Embora oauthlib atualmente não faça nada para sugerir que o campo de cabeçalho 'WWW-Authenticate' deva ser incluído na resposta conforme a especificação exige. Eu acho que manter 401 para este erro está ok, mas devemos adicionar uma sugestão de cabeçalho à exceção.

Quanto ao outro, a especificação não diz explicitamente que 401 pode ser usado e, portanto, provavelmente devemos considerar a mudança para 400. No entanto, parece mais apropriado com um 401 em concessão inválida e especialmente erros de cliente não autorizados.

@asteinlein , @lepture , @masci pensamentos?

@ib-lundgren Oi - acabei de me deparar com esse problema e gostaria de entrar na conversa. Ao ler as especificações e pesquisar outras respostas, IMO a 400 é a resposta correta.

Em primeiro lugar, a especificação:

O servidor de autorização responde com um HTTP 400 (Bad Request)
código de status (a menos que especificado de outra forma) e inclui o seguinte
parâmetros com a resposta:

Não há DEVE nos requisitos 400, mas também não há MAY.

Em segundo lugar, e a razão pela qual me deparei com isso foi por meio de um tipo de bug no sol JDK no meu cliente (veja aqui: http://stackoverflow.com/a/7524681/1137254 )

Essencialmente, a pilha HTTP do meu cliente fecharia a conexão antecipadamente para um 401, mas a pilha OAuth acima (google-http-oauth-client) tentaria continuar lendo e analisar os resultados. Eu acho que isso foi escrito no OpenJDK pela definição e expectativas em torno de um 401 (ATUALIZAÇÃO: na verdade tem a ver com o modo 'streaming'). O IMO OpenJDK também está errado e acho que encontraria esse mesmo problema se obtivesse um "invalid_client" 401 durante solicitações de ponto de extremidade /token.

Adicionando outro voto para 400 sendo o código de erro correto aqui. Costumávamos usar django-oauth2-provider para autenticação oauth2 de aplicativos móveis e ele retornou 400 neste caso. Ao mudar para django-oauth-toolkit (que usa oauthlib) para atualizar para versões mais recentes do Django, tivemos que hackear a visualização de solicitação de token para retornar um 400 em vez de manter os aplicativos móveis funcionando corretamente.

Aqui está um dos autores da especificação declarando especificamente que um 400 é a resposta pretendida para credenciais de autenticação inválidas ao solicitar um token e por quê: https://www.ietf.org/mail-archive/web/oauth/current/msg02127 .html

E aqui está outro exemplo de um projeto que está tendo problemas para lidar com oauthlib usando um 401 nessas circunstâncias.

+1 por 400

Vote em 400

Estou revivendo este tópico antigo e iniciar um PR com as alterações sugeridas acima.

Antes de avançar nisso, gostaria de resumir a discussão que aconteceu no passado.

• O grupo de trabalho OAuth2.0 RFC6749 decidiu adotar 400 para status HTTP de erro em vez de 401, porque requer que WWW-Authenticate seja definido e nem sempre é possível em todas as respostas de erros.
• @asteinlein propôs um PR em https://github.com/oauthlib/oauthlib/pull/247 para alterar os erros do oauthlib de 400 para 401, porque _alguns clientes parecem esperar 401 para chamadas de API relacionadas à autorização_. Embora tivesse que ser verdade, não sabemos quais clientes foram quebrados.
• Vários bugs aparecem em bibliotecas de terceiros https://github.com/oauthjs/angular-oauth2/issues/31 https://github.com/oauthjs/angular-oauth2/issues/32#issuecomment -88888755 https://github .com/oauthjs/angular-oauth2/issues/36 . As questões estão todas encerradas agora.
• O consenso geral do thread atual, e também RFC6749#5.2 , é que todos os 401 em oauthlib devem ser 400 . No entanto, temos dois casos com 401 :

1. invalid_client , onde DEVE ser 401 se a autenticação HTTP for usada, senão PODE ser 401 .
2. invalid_token , onde DEVE ser 401 .

Em qualquer caso, se 401 for usado, WWW-Authenticate DEVE ser definido ( RFC2616 ).

Outras implementações do OAuth2.0

Uma rápida visão geral das implementações OAuth2.0 mais comuns é semelhante ao consenso geral:

• O Google retorna 400 so-question / so-question .
• O Salesforce retorna 400 salesforce-forum .
• Azur retorna 401 com WWW-Authenticate azur-docs .
• A AWS retorna 400 aws-cognito-docs . Eles quebraram o " DEVE " do RFC para ser 401 quando a autenticação HTTP é usada.

Conclusão

Temos que nos alinhar com a RFC, porém para não quebrar nenhuma implementação, não devemos incluir essas mudanças na versão 2.xx, mas esperar até 3.xx

Por favor, sinta-se à vontade para entrar em contato.

Não consigo lembrar o motivo/os clientes que me fizeram pressionar a PR #247, mas vejo e entendo os motivos para reverter isso. Obrigado pela pesquisa incrível @JonathanHuot , e fazer isso em 3.x parece a melhor abordagem.

Corrigido em #561 / oauthlib>= 3.0.0

de acordo com esta RFC que mencionou acima o cliente inválido também deve retornar o status 400 mas no pacote ainda é 401

Oi @esfandiaryfard , você poderia apontar o texto exato da RFC? Obrigado!