Coisas importantes que você precisa saber sobre oauth

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

A idéia é permitir que os aplicativos do cliente tenha acesso limitado às informações do usuário sem compartilhar credenciais ou senha do usuário. O OAuth Framework é responsável pelas trocas necessárias antes que um aplicativo obtenha suas informações.

Suponha que você queira se inscrever no dev.para (que é um ótimo lugar para os desenvolvedores trocarem idéias), eles permitem que você se inscreva usando sua conta do GitHub. Como isso acontece? Como eles saberiam que você é dono da conta do GitHub, que está se inscrevendo?

Mais importante, como você garante que o dev.não está ultrapassando seus limites quando se trata de suas informações armazenadas com o GitHub?

OAuth participantes

Vamos seguir o exemplo do plugin Github do Editor Atom, que permite aos desenvolvedores empurrar o código para o github diretamente usando a interface Atom. A razão para isso como exemplo é porque o Github não esconde os detalhes atrás da cena e você pode ver o que está acontecendo sob o capô.

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

1. Proprietário ou usuário do recurso: Este usuário é aquele cujas informações de conta precisam ser acessadas (leia e/ou gravar) para fazê -lo funcionar 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 Atom Editor é o cliente.
3. Recurso: Recurso é sua informação real sentada nos servidores em algum local remoto. Isso pode ser acessado por meio de uma API se o cliente tiver permissões apropriadas.
4. Servidor de autorização: Também interfigurado com uma API. Este servidor é mantido pelo provedor de serviços (github em nosso exemplo). Tanto o servidor de autorização quanto o servidor de recursos são chamados de API porque são gerenciados por uma entidade, neste caso Github, e expostos como uma API ao desenvolvedor do cliente.

Registro de Oauth

O processo começa quando o aplicativo cliente está sendo desenvolvido. Você pode ir ao 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 de chamada, onde o usuário seria redirecionado após aceitar ou rejeitar para fornecer o aplicativo Permissões necessárias.

Por exemplo, se você for ao GitHub → Configurações → Configurações do desenvolvedor e clique em “Registre 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ê deve Mantenha -os seguros e seguros, pois não serão mostrados pelo servidor de autorização novamente. O mesmo vale para qualquer outro tokens que seria jogado (mais em tokens mais tarde).

OAuth 2 Fluxo de trabalho

Você registrou seu aplicativo. Foi desenvolvido e testado e agora os usuários estão prontos para usá -lo. Um novo usuário ao se registrar no seu serviço seria mostrado a opção de “entrar com o 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) se abre com a página da web do recurso e pede aos usuários que login. Se você já está conectado, nesse dispositivo, esta etapa é ignorada e você é simplesmente perguntado pelo Github se deseja dar acesso ao aplicativo do Atom Client. Isso é muito mais transparente no caso de Atom, porque eles pedem que você vá manualmente ao site do GitHub e conceda a permissão.

Ao visitar o URL, você solicita a permissão.

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

Ao contrário do Atom, a maioria dos aplicativos clientes 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 é redirecionado e verifique se está correto URL 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 é enviada ao cliente Atom.

Depois que o usuário faz isso, o trabalho do usuário é feito. (De fato, um usuário típico nem sequer está ciente da bolsa de troca de autorização. O exemplo de Github foi escolhido para mostrar que é isso que acontece).

Etapa 3: Obtendo 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. Que é obtido usando algo chamado token de acesso. Qual aplicativo do cliente tentará entrar 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 e o segredo do cliente que foram dados ao aplicativo cliente anteriormente.

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

Depois que a identidade é verificada e a concessão de 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 pode ser dada ao servidor de recursos para acessar um recurso protegido específico que o proprietário do recurso permitiu que você acesse.

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

Observe, como em toda essa troca o nome de usuário e a senha real, onde nunca compartilhou com o cliente? Essa é a beleza de Oauth. Em vez de dar nome de usuário e senhas que concederia ao aplicativo todo o acesso ao recurso, ele usa tokens. E um token pode obter apenas um acesso limitado ao recurso.

Revocando permissões

Suponha que você perca o acesso ao seu dispositivo que tinha o aplicativo de cliente autorizado nele. Você pode fazer login no github e ir para configurações → aplicações → aplicativos autorizados do OAuth para revogar a concessão de autorização e o token de acesso. Eu estarei fazendo o mesmo, pois, nas capturas de tela acima, a concessão de autorização foi mostrada publicamente.

Agora que você tem uma visão olho de pássaro de como Oauth 2.Você pode ler mais sobre as doações de autorização e outros detalhes mais delicados do protocolo e como as chamadas da API são feitas aqui.