OAuth 2.0: benefícios e casos de uso - por que?

Alguém poderia explicar o que é bom no OAuth2 e por que devemos implementá-lo? Eu pergunto porque estou um pouco confuso sobre isso - eis os meus pensamentos atuais:

As solicitações do OAuth1 (mais precisamente HMAC) parecem lógicas, fáceis de entender, fáceis de desenvolver e realmente muito seguras.

Em vez disso, o OAuth2 traz solicitações de autorização, tokens de acesso e tokens de atualização, e você precisa fazer três solicitações no início de uma sessão para obter os dados que procura. E mesmo assim, uma de suas solicitações acabará falhando quando o token expirar.

E para obter outro token de acesso, use um token de atualização que foi passado ao mesmo tempo que o token de acesso. Isso torna o token de acesso inútil do ponto de vista da segurança?

Além disso, como o / r / netsec mostrou recentemente, o SSL não é totalmente seguro; portanto, o esforço para colocar tudo no TLS / SSL em vez de um HMAC seguro me confunde.

OAuth está argumentando que não se trata de 100% de segurança, mas de publicá-lo e finalizá-lo. Isso não parece exatamente promissor do ponto de vista de um provedor. Eu posso ver o que o rascunho está tentando alcançar quando menciona os 6 fluxos diferentes, mas simplesmente não se encaixa na minha cabeça.

Acho que pode ser mais difícil entender os benefícios e o raciocínio do que realmente não gostar dele, então isso pode ser um ataque injustificado e desculpe se isso pode parecer um discurso retórico.

Histórico: escrevi pilhas de clientes e servidores para o OAuth 1.0a e 2.0.

O OAuth 1.0a e 2.0 suportam autenticação de duas pernas , onde um servidor tem a identidade de um usuário, e autenticação de três pernas , onde um servidor é garantido por um provedor de conteúdo da identidade do usuário. A autenticação de três pernas é onde as solicitações de autorização e os tokens de acesso entram em ação, e é importante observar que o OAuth 1 também os possui.

O complexo: autenticação de três pernas

Um ponto principal das especificações do OAuth é que um provedor de conteúdo (por exemplo, Facebook, Twitter etc.) garanta a um servidor (por exemplo, um aplicativo da Web que deseja conversar com o provedor de conteúdo em nome do cliente) que o cliente tenha alguma identidade . O que a autenticação de três pernas oferece é a capacidade de fazer isso sem que o cliente ou o servidor precise conhecer os detalhes dessa identidade (por exemplo, nome de usuário e senha).

Sem (?) Se aprofundar nos detalhes do OAuth:

1. O cliente envia uma solicitação de autorização ao servidor, que valida que o cliente é um cliente legítimo de seu serviço.
2. O servidor redireciona o cliente ao provedor de conteúdo para solicitar acesso aos seus recursos.
3. O provedor de conteúdo valida a identidade do usuário e geralmente solicita sua permissão para acessar os recursos.
4. O provedor de conteúdo redireciona o cliente de volta ao servidor, notificando-o de êxito ou falha. Essa solicitação inclui um código de autorização com êxito.
5. O servidor faz uma solicitação fora de banda ao provedor de conteúdo e troca o código de autorização por um token de acesso.

O servidor agora pode fazer solicitações ao provedor de conteúdo em nome do usuário, passando o token de acesso.

Cada troca (cliente-> servidor, servidor-> provedor de conteúdo) inclui a validação de um segredo compartilhado, mas como o OAuth 1 pode ser executado em uma conexão não criptografada, cada validação não pode transmitir o segredo pela conexão.

Isso é feito, como você observou, com o HMAC. O cliente usa o segredo que compartilha com o servidor para assinar os argumentos para sua solicitação de autorização. O servidor aceita os argumentos, assina-os com a chave do cliente e pode ver se é um cliente legítimo (na etapa 1 acima).

Essa assinatura exige que o cliente e o servidor concordem com a ordem dos argumentos (para que eles assinem exatamente a mesma string), e uma das principais reclamações sobre o OAuth 1 é que exige que o servidor e os clientes classifiquem e assinar de forma idêntica. Este é um código complicado e está certo ou você recebe 401 Unauthorizedpouca ajuda. Isso aumenta a barreira para escrever um cliente.

Ao exigir que a solicitação de autorização seja executada sobre SSL, o OAuth 2.0 elimina completamente a necessidade de classificação e assinatura de argumentos. O cliente passa seu segredo para o servidor, que o valida diretamente.

Os mesmos requisitos estão presentes na conexão servidor-> provedor de conteúdo e, como é o SSL que remove uma barreira na gravação de um servidor que acessa os serviços OAuth.

Isso facilita muito as coisas nas etapas 1, 2 e 5 acima.

Portanto, neste ponto, nosso servidor possui um token de acesso permanente, equivalente ao nome de usuário / senha do usuário. Ele pode fazer solicitações ao provedor de conteúdo em nome do usuário, passando esse token de acesso como parte da solicitação (como argumento de consulta, cabeçalho HTTP ou dados do formulário POST).

Se o serviço de conteúdo for acessado apenas por SSL, terminamos. Se estiver disponível via HTTP simples, gostaríamos de proteger esse token de acesso permanente de alguma forma. Qualquer pessoa que fareje a conexão poderá obter acesso ao conteúdo do usuário para sempre.

A maneira resolvida no OAuth 2 é com um token de atualização . O token de atualização se torna o equivalente da senha permanente e só é transmitido por SSL . Quando o servidor precisa de acesso ao serviço de conteúdo, ele troca o token de atualização por um token de acesso de curta duração. Dessa forma, todos os acessos HTTP sniffable são feitos com um token que expira. O Google está usando uma expiração de 5 minutos em suas APIs do OAuth 2.

Portanto, além dos tokens de atualização, o OAuth 2 simplifica todas as comunicações entre o cliente, o servidor e o provedor de conteúdo. E os tokens de atualização existem apenas para fornecer segurança quando o conteúdo está sendo acessado sem criptografia.

Autenticação de duas pernas

Às vezes, porém, um servidor só precisa controlar o acesso ao seu próprio conteúdo. A autenticação de duas pernas permite que o cliente autentique o usuário diretamente no servidor.

O OAuth 2 padroniza algumas extensões do OAuth 1 que eram amplamente utilizadas. O que eu conheço melhor foi apresentado pelo Twitter como xAuth . Você pode vê-lo no OAuth 2 como credenciais de senha do proprietário do recurso .

Essencialmente, se você puder confiar no cliente as credenciais do usuário (nome de usuário e senha), ele poderá trocá-las diretamente com o provedor de conteúdo por um token de acesso. Isso torna o OAuth muito mais útil em aplicativos móveis - com autenticação de três pernas, você precisa incorporar uma exibição HTTP para lidar com o processo de autorização com o servidor de conteúdo.

Com o OAuth 1, isso não fazia parte do padrão oficial e exigia o mesmo procedimento de assinatura que todos os outros pedidos.

Acabei de implementar o lado do servidor do OAuth 2 com credenciais de senha do proprietário do recurso e, da perspectiva de um cliente, obter o token de acesso tornou-se simples: solicite um token de acesso ao servidor, passando a id / segredo do cliente como um cabeçalho de autorização HTTP e o login / senha do usuário como dados do formulário.

Vantagem: Simplicidade

Portanto, da perspectiva de um implementador, as principais vantagens que vejo no OAuth 2 estão na complexidade reduzida. Não requer o procedimento de assinatura de solicitação, o que não é exatamente difícil, mas certamente é complicado. Isso reduz bastante o trabalho necessário para atuar como cliente de um serviço, que é o local onde (no mundo moderno e móvel) você mais deseja minimizar a dor. A complexidade reduzida no servidor-> provedor de conteúdo final o torna mais escalável no datacenter.

E codifica no padrão algumas extensões do OAuth 1.0a (como xAuth) que agora estão sendo amplamente utilizadas.

Primeiro, conforme indicado claramente na autenticação OAuth

OAuth 2.0 não é um protocolo de autenticação.

A autenticação no contexto de um usuário acessando um aplicativo informa a um aplicativo quem é o usuário atual e se está presente ou não. Um protocolo de autenticação completo provavelmente também informará vários atributos sobre esse usuário, como um identificador exclusivo, um endereço de email e como chamá-los quando o aplicativo disser "Bom dia".

No entanto, o OAuth não diz ao aplicativo nada disso. OAuth não diz absolutamente nada sobre o usuário, nem diz como o usuário provou sua presença ou mesmo se ainda está lá. No que diz respeito a um cliente OAuth, ele solicitou um token, obteve um token e, eventualmente, usou esse token para acessar alguma API. Ele não sabe nada sobre quem autorizou o aplicativo ou se havia mesmo um usuário lá.

Há um padrão para autenticação de usuário usando o OAuth: OpenID Connect, compatível com o OAuth2.

O OpenID Connect ID Token é um JSON Web Token (JWT) assinado que é fornecido ao aplicativo cliente ao lado do token de acesso normal do OAuth. O Token de ID contém um conjunto de declarações sobre a sessão de autenticação, incluindo um identificador para o usuário (sub), o identificador para o provedor de identidade que emitiu o token (iss) e o identificador do cliente para o qual esse token foi criado ( aud).

No Go, você pode procurar por coreos / dex, um OIDC (OpenID Connect Identity) e um provedor OAuth 2.0 com conector conectável.

Resposta deste post vonc

Eu responderia a essa pergunta de maneira um pouco diferente e serei muito preciso e breve, principalmente porque @ Peter T respondeu a tudo.

O principal ganho que vejo deste padrão é respeitar dois princípios:

1. Separação de preocupações.
2. Desacoplar a autenticação do aplicativo Web, que geralmente serve aos negócios.

Ao fazê-lo,

1. Você pode implementar uma alternativa ao Logon único: se você tiver vários aplicativos que confiam em um STS. O que quero dizer, um nome de usuário para todos os aplicativos.
2. Você pode ativar seu aplicativo da web (O cliente) para acessar recursos que pertencem ao usuário e não pertencem ao aplicativo da web (O cliente).
3. Você pode ordenar o processo de autenticação a terceiros nos quais confia e nunca se preocupar com a validação da autenticidade do usuário.