Coisas importantes que você precisa saber sobre o OAuth

OAuth é algo que todo desenvolvedor deve saber. Se você estiver criando um aplicativo autônomo ou um aplicativo de terceiros que se integra a algum outro serviço HTTP, precisa saber como o OAuth funciona para fornecer aos seus usuários um serviço fácil de usar e bem integrado.

A ideia é permitir que os aplicativos clientes tenham acesso limitado às informações do usuário, sem nunca compartilhar as credenciais ou a senha do usuário. A estrutura OAuth é responsável pelas trocas necessárias antes que um aplicativo obtenha suas informações.

Suponha que você queira se inscrever para Dev.para (que é um ótimo lugar para os desenvolvedores trocarem ideias) eles permitem que você se inscreva usando sua conta do GitHub. Como isso acontece? Como eles saberiam que você possui a conta do GitHub, com a qual está se inscrevendo?

Mais importante, como você garante que Dev.não é ultrapassar seus limites quando se trata de suas informações armazenadas com GitHub?

Participantes OAuth

Seguiremos o exemplo do plug-in GitHub do editor Atom, que permite que os desenvolvedores enviem código para o GitHub diretamente usando a interface Atom. A razão para isso como um exemplo é porque o GitHub não esconde os detalhes por trás da cena e você consegue ver o que está acontecendo nos bastidores.

Antes de entrarmos nas minúcias do trabalho do OAuth. Vamos definir o cenário reconhecendo todos os participantes da troca:

1. Proprietário ou usuário do recurso: Este usuário é aquele cujas informações da conta precisam ser acessadas (leitura e / ou gravação) para que funcionem com um aplicativo.
2. Cliente: Este é o aplicativo que está buscando sua permissão para acessar suas informações de um serviço diferente. Em nosso exemplo, o editor Atom é o cliente.
3. Recurso: O recurso é a sua informação real nos servidores em algum local remoto. Isso pode ser acessado por meio de uma API se o cliente receber as permissões adequadas.
4. Servidor de Autorização: Também com interface por meio de uma API. Este servidor é mantido pelo provedor de serviços (GitHub em nosso exemplo). O servidor de autorização e o servidor de recursos são chamados de API porque são gerenciados por uma entidade, neste caso o GitHub, e expostos como uma API para o desenvolvedor do cliente.

Registro OAuth

O processo começa quando o aplicativo do cliente está sendo desenvolvido. Você pode acessar o provedor de recursos e se inscrever no portal do desenvolvedor ou na seção API do site. Você também terá que fornecer um URL de retorno em que o usuário seria redirecionado após aceitar ou rejeitar para dar ao aplicativo as permissões necessárias.

Por exemplo, se você acessar GitHub → Configurações → Configurações do desenvolvedor e clicar em “Registrar um novo aplicativo”. Isso forneceria a você um ID do Cliente que pode ser tornado público e um Segredo do cliente que, a organização do desenvolvedor deve manter ... bem, um segredo.

Depois que o ID do cliente e o segredo são fornecidos a você, o desenvolvedor, você devo mantê-los protegidos e protegidos, pois eles não serão mostrados pelo servidor de autorização novamente. O mesmo se aplica a quaisquer outros tokens que seriam lançados (mais sobre tokens posteriormente).

Fluxo de trabalho OAuth 2

Você registrou seu aplicativo. Ele foi desenvolvido e testado e agora os usuários estão prontos para usá-lo. Um novo usuário, ao se registrar em seu serviço, verá a opção de “Sign in with GitHub”. Este é o primeiro passo.

Etapa 1: solicitação de autorização

A solicitação de autorização é a parte em que uma nova janela (ou um prompt semelhante) abre com a página da Web do recurso e pede aos usuários para fazer o login. Se você já estiver conectado nesse dispositivo, esta etapa será ignorada e o GitHub simplesmente perguntará se deseja conceder acesso ao aplicativo cliente Atom. Isso é muito mais transparente no caso do Atom porque eles pedem que você acesse manualmente o site do GitHub e conceda a permissão.

Ao visitar o URL, é solicitada a permissão.

Observe o URL que mostra que esta é uma página da web segura (HTTPS) do GitHub.Inc. Agora você, o usuário, pode ter certeza de que está interagindo diretamente com o GitHub. O Atom está simplesmente esperando, bastante afastado.

Ao contrário do Atom, a maioria dos aplicativos cliente carrega automaticamente a página de login ou permissões. Embora seja muito conveniente, também pode ser mal utilizado, se o aplicativo cliente decidir abrir um link de phishing. Para evitar isso, você deve sempre verificar o URL para o qual você é redirecionado e certificar-se de que é o URL correto e está usando o protocolo HTTPS.

Etapa 2: Obtendo a Concessão de Autorização

Para notificar o cliente Atom, você recebe um token (uma concessão de autorização) que é então enviado ao cliente Atom.

Assim que o usuário fizer isso, o trabalho do usuário estará concluído. (Na verdade, um usuário típico nem mesmo está ciente sobre a troca de concessão de autorização. O exemplo do GitHub foi escolhido para mostrar que é isso que acontece).

Etapa 3: obter o token de acesso

A concessão de autorização ainda não é a entidade que dá ao cliente acesso às informações do usuário. Isso é obtido usando algo chamado token de acesso. Qual o aplicativo cliente tentará obter nesta etapa.

Para fazer isso, o cliente agora terá que fornecer a concessão de autorização ao servidor de autorização junto com uma prova de sua própria identidade. A identidade é verificada usando o ID do cliente e o segredo do cliente que foram fornecidos ao aplicativo cliente anteriormente.

A verificação de identidade é feita para garantir que o usuário não seja induzido a usar um aplicativo nefasto que finge ser um aplicativo legítimo. Por exemplo, se alguém decidir nomear seu executável como Atom com o mesmo nome, logotipo e funcionalidade, o usuário pode ser induzido a fornecer acesso a um cliente que pode usar indevidamente suas informações. Eles podem bisbilhotar ou até mesmo agir sem o seu consentimento. O servidor de autorização garante que o cliente é realmente o que parece para seus usuários.

Depois que a identidade é verificada e a concessão da autorização é aceita, o servidor de autorização lança um token para o aplicativo cliente. Pense no token como uma combinação de nome de usuário e senha que podem ser fornecidos ao servidor de recursos para acessar um recurso protegido específico que o proprietário do recurso permitiu que você acessasse.

Finalmente, usando este token, o aplicativo agora pode obter acesso às informações necessárias do usuário e outros recursos do servidor de recursos.

Observe como em toda essa troca o nome de usuário e a senha reais nunca foram compartilhados com o cliente? Essa é a beleza do OAuth. Em vez de fornecer nome de usuário e senhas que concederiam ao aplicativo todo o acesso ao recurso, ele usa tokens. E um token pode obter apenas um acesso limitado ao recurso.

Revogando permissões

Suponha que você perca o acesso ao seu dispositivo que continha o aplicativo cliente autorizado. Você pode fazer login no GitHub e ir para Configurações → Aplicativos → Aplicativos OAuth autorizados para revogar a concessão de autorização e o token de acesso. Farei o mesmo, pois, nas imagens acima, a concessão de autorização foi mostrada publicamente.

Agora que você tem uma visão panorâmica de como OAuth 2.Você pode ler mais sobre as concessões de autorização e outros detalhes mais precisos do protocolo e como as chamadas de API são feitas aqui.