O que você precisa saber sobre OAuth2 e fazer login com o Facebook

Caso você esteja se perguntando o que é OAuth2, é o protocolo que permite que qualquer pessoa faça login com sua conta do Facebook. Ele ativa o botão “Fazer login com o Facebook” em aplicativos e sites em todos os lugares.

Este artigo mostra como o “Log in with Facebook” funciona e explica o protocolo por trás de tudo. Você aprenderá por que deseja fazer login com o Facebook, Google, Microsoft ou uma das muitas outras empresas que oferecem suporte ao OAuth2.

Este artigo mostra como o “Log in with Facebook” funciona e explica o protocolo por trás de tudo. Você aprenderá por que deseja fazer login com o Facebook, Google, Microsoft ou uma das muitas outras empresas que oferecem suporte ao OAuth2.

Veremos dois exemplos: por que o Spotify usa o Facebook para permitir que você faça login no aplicativo móvel Spotify e por que o Quora usa o Google e o Facebook para permitir que você faça login em seu site.

Leitura adicional no SmashingMag:

• Quatro maneiras de construir um aplicativo móvel
• Como criar interfaces de usuário honestas e ajudar os usuários a tomar melhores decisões
• Mantendo seu aplicativo Android popular após o lançamento
• Listas de reprodução do Spotify para alimentar suas sessões de codificação e design
  

Antes do OAuth2

OAuth2 venceu uma batalha de padrões há alguns anos. É o único protocolo de autenticação suportado pelos principais fornecedores. O Google recomenda o OAuth2 para todas as suas APIs, e a Graph API do Facebook oferece suporte apenas ao OAuth2.

A melhor maneira de entender o OAuth2 é observar o que veio antes dele e por que precisávamos de algo diferente. Tudo começou com a autenticação básica.

Autenticação básica

Os esquemas de autenticação se concentram em duas questões-chave: Quem é você? E você pode provar isso?

A maneira mais comum de fazer essas duas perguntas é com um nome de usuário e senha. O nome de usuário diz quem você é, e a senha prova isso.

A autenticação básica foi o primeiro esquema de autenticação da web. Parece engraçado, mas “autenticação básica” era seu nome real na especificação publicada pela primeira vez em 1999.

A autenticação básica permite que os servidores da Web solicitem essas credenciais de uma maneira que os navegadores entendam. O servidor retorna um código de resposta HTTP 401 (o que significa que a autenticação é necessária) e adiciona um cabeçalho especial à resposta, chamado WWW-Authenticate , com um valor especial Basic .

Quando o navegador vê esse código de resposta e esse cabeçalho, ele mostra uma caixa de diálogo pop-up de login:

A grande parte do Basic Auth é sua simplicidade. Você não precisa escrever uma tela de login. O navegador lida com tudo isso e apenas envia o nome de usuário e a senha para o servidor. Ele também dá ao navegador a chance de lidar especialmente com a senha, seja lembrando-a para o usuário, obtendo-a de um plug-in de terceiros ou obtendo as credenciais do usuário de seu sistema operacional.

A desvantagem é que você não tem nenhum controle sobre a aparência da tela de login. Isso significa que você não pode estilizá-lo ou adicionar novas funcionalidades, como "Esqueceu a senha?" link ou uma opção para criar uma nova conta. Se você quiser mais personalização, terá que escrever um formulário de login personalizado.

Formulários de login personalizados

Os formulários de login personalizados oferecem todo o controle que você deseja. Você escreve um formulário HTML e solicita as credenciais. Em seguida, você envia o formulário e lida com o login da maneira que desejar. Você obtém controle total: você pode estilizá-lo, pedir mais detalhes ou adicionar mais links.

Alguns sites, como o WordPress, usam um formulário simples para a tela de login:

O LinkedIn permite que os usuários façam login ou criem uma conta na mesma página, sem precisar ir para outra parte do site:

O login baseado em formulário é muito popular, mas tem um grande problema fundamental: os usuários precisam informar ao site sua senha.

Mantendo segredos em segredo

Nos círculos de segurança, chamamos uma senha de segredo. É uma informação que só você tem e prova que você é você. O segredo também pode ser mais do que apenas uma senha; falaremos mais sobre isso um pouco mais tarde.

Um site pode tomar todas as medidas de segurança do mundo, mas se o usuário compartilhar sua senha, essa segurança desaparece. Hackers invadiram o site Gawker em 2010, expondo as senhas de muitos usuários. Embora isso fosse um problema para o Gawker, o problema não parou por aí. A maioria das pessoas reutiliza senhas, então os hackers pegaram os dados vazados do Gawker e tentaram fazer login em sites mais críticos, como Gmail, Facebook e eBay. Qualquer um que usou uma senha do Gawker para coisas mais importantes perdeu muito mais do que as últimas fofocas sobre a fita de sexo de Hulk Hogan.

Garantir que seus usuários não reutilizem uma senha para várias contas é a primeira metade do problema — e é impossível. Enquanto as pessoas tiverem que criar contas diferentes em toda a Internet, elas reutilizarão suas senhas.

A segunda metade do problema é armazenar as senhas com segurança.

Quando alguém faz login no seu aplicativo, você precisa verificar a senha, e isso significa que você precisa de uma cópia para verificá-la. Você poderia armazenar todos os nomes de usuário e senhas em um banco de dados em algum lugar, mas agora corre o risco de perder essas senhas ou ser hackeado. A melhor prática é usar uma função de hash, como uma das funções SHA-2. Essa função criptografa os dados de uma maneira que você nunca pode recuperá-los, mas pode replicar a criptografia: “minha senha” será hash para algo como bb14292d91c6d0920a5536bb41f3a50f66351b7b9d94c804dfce8a96ca1051f2 todas as vezes.

E agora estamos na grama alta: estou lhe dizendo como implementar protocolos criptográficos. Em seguida, terei que explicar como adicionar um sal aos seus dados e quais livros ler sobre ataques man-in-the-middle. Tudo o que você queria fazer era escrever um aplicativo e agora precisa se tornar um especialista em segurança. Precisamos dar um passo atrás.

OAuth2

Você provavelmente não é um especialista em segurança. Mesmo se você for, eu ainda não confiaria em você com minha senha. OAuth2 oferece uma maneira melhor.

Como exemplo, eu uso o Spotify no meu iPad. Eu pago à empresa US$ 10 por mês para ouvir música. O Spotify me dá acesso em apenas três dispositivos, então preciso de uma senha para garantir que ninguém mais use minha conta. Minha conta do Spotify não é uma grande preocupação de segurança. Ser hackeado não seria o fim do mundo, mas a empresa tem meu cartão de crédito, então quero ter certeza de que estou seguro.

Eu quase nunca entro no Spotify, então não quero criar outra conta e ter que lembrar de outra senha. Spotify me dá uma opção melhor:

Eu posso usar minha conta do Facebook para fazer login. Quando eu toco nesse botão, o Spotify me envia para facebook.com, e eu faço login lá. Isso pode parecer um pequeno detalhe, mas é o passo mais importante de todo o processo.

Os programadores do Spotify poderiam ter escrito um formulário de login e, em seguida, enviado meu nome de usuário e senha para o Facebook com uma API de back-end, mas há duas grandes razões pelas quais eu não quero que eles façam isso:

• Não confio no Spotify com minha senha do Facebook. Eu uso o Facebook para me conectar com amigos e não quero ser hackeado. Eu não confio que o Spotify irá lidar com a senha corretamente. Também não acredito que isso evitará a tentação de fazer algo engraçado com ele. Talvez tentasse armazená-lo para poder usá-lo mais tarde. Talvez tenha um bug que o grava em um arquivo em algum lugar antes de enviá-lo para o Facebook, para que um hacker possa pegá-lo. Desculpe, Spotify; Só não sou do tipo que confia.
• Não quero deixar o Spotify fazer tudo. Eu quero que o Spotify toque música. Eu não quero postar nas paredes dos meus amigos quando eu escuto as Spice Girls. Eu também não quero deixá-lo baixar minha lista de amigos e incomodá-los para entrar no Spotify. Se eu desse ao Spotify minha senha do Facebook, ele poderia fazer login como eu no Facebook; poderia fazer qualquer coisa que eu pudesse fazer.

Há também duas grandes razões pelas quais o Spotify não quer fazer isso:

• O Facebook tem várias opções para eu fazer login. . Eu posso fazer login com meu nome de usuário e senha ou posso fazer login com o aplicativo do Facebook. Também posso recuperar minha senha do Facebook ou obter ajuda que o Spotify não pode me dar. Se eu apenas desse minha senha ao Spotify, não teria nenhuma dessas opções.
• Meu segredo pode não ser uma senha. . Uma senha é segurança suficiente para minha conta Spotify de US$ 10 por mês, mas pode não ser suficiente para meu banco ou algo ainda mais importante. Há muitos outros segredos que eu poderia fornecer: posso ter um cartão inteligente ou posso estar vivendo em um filme de Missão Impossível e usar um scanner de retina.

Não estou em um filme de Missão Impossível, mas no mundo real, muitas empresas usam autenticação de dois fatores, como uma senha e outra coisa. O método mais comum é usar o telefone. Quando você deseja fazer login, a empresa envia um texto com um código especial que dura alguns minutos; você digita o código ou usa um aplicativo para inseri-lo.

Agora a empresa tem certeza de que ninguém pode fazer login na sua conta sem o seu telefone. Se alguém roubar sua senha, ainda assim não poderá fazer login. Contanto que você não perca seu telefone, tudo estará seguro.

O Facebook não é o único provedor OAuth2. Quando entro no Quora com minha conta do Google, o Google me diz o que o Quora gostaria de fazer e pergunta se está tudo bem:

Posso permitir que o Quora visualize meu endereço de e-mail e meus dados básicos de perfil, mas não quero que ele gerencie meus contatos. OAuth2 me mostra todo o acesso que o Quora deseja, permitindo que eu escolha o que eu concedo acesso.

Então, essas são as vantagens do OAuth2. Vamos ver como isso funciona.

Como funciona o OAuth2

Facebook, Google e a maioria dos outros provedores OAuth2 tratam os clientes nativos de forma diferente dos clientes da web. Os clientes nativos são considerados mais seguros e obtêm tokens e tokens de atualização que podem durar meses. Os clientes da Web obtêm tokens muito mais curtos, que normalmente expiram quando o usuário fecha o navegador ou não clica no site há algum tempo.

Em ambos os casos, o processo de login é o mesmo. A diferença está na frequência com que o usuário precisa passar por isso.

O login do OAuth2 segue estas etapas gerais:

1. O usuário tenta fazer algo que requer autenticação. Isso pode ser tão simples quanto abrir um aplicativo ou clicar em um botão “Log in”.
2. O aplicativo ou site determina que o usuário ainda não fez login e inicia o processo de login. Ele faz isso abrindo uma página da web e enviando-a para uma URL especial no Facebook, Google ou qualquer outro site que esteja fornecendo seu OAuth2.

Abrir uma nova janela do navegador para o provedor OAuth2 é uma etapa crucial. É isso que permite que os provedores mostrem seus próprios formulários de login e solicitem a cada usuário as informações de login de que precisam. A maioria dos aplicativos faz isso com uma visualização da Web incorporada.

Junto com o URL de login do provedor, você precisa enviar alguns parâmetros de URL que informam ao provedor quem você é e o que deseja fazer:

• client_id Isso informa ao provedor OAuth2 qual é o seu aplicativo. Você precisará registrar seu aplicativo com antecedência para obter um ID de cliente.
• redirect_uri Isso diz ao provedor para onde você quer ir quando terminar. Para um site, isso pode estar de volta à página principal; um aplicativo nativo pode ir para uma página que fecha a visualização da web.
• response_type Isso informa ao provedor o que você deseja de volta. Normalmente, esse valor é token , para indicar que você deseja um token de acesso, ou code , para indicar que deseja um código de acesso. Os provedores também podem estender esse valor para fornecer outros tipos de dados.
• scope Isso informa ao provedor o que seu aplicativo deseja acessar. É assim que o Google sabe que o Quora está pedindo acesso para gerenciar seus contatos. Cada provedor tem um conjunto diferente de escopos.

Existem campos adicionais que podem adicionar mais segurança ou ajudar no armazenamento em cache. Alguns provedores também adicionam mais campos, mas esses quatro são os mais importantes.

Depois que seu aplicativo abre a visualização da Web, o provedor assume. Eles podem apenas pedir um nome de usuário e senha simples, ou podem apresentar várias telas solicitando qualquer coisa, desde o nome do seu professor favorito até o nome de solteira da sua mãe. Isso é tudo com eles. A parte importante é que, quando o provedor terminar, ele o redirecionará de volta para você e lhe dará um token.

É tudo sobre os tokens

Quando o processo for concluído, o provedor fornecerá um token e um tipo de token. Existem dois tipos de tokens: tokens de acesso e tokens de atualização. O tipo de cliente que você tem determinará quais tipos de tokens você pode solicitar.

Quando entro no meu aplicativo Spotify, posso ficar conectado por meses, porque a suposição é que meu telefone é usado apenas por mim. O Facebook confia no aplicativo Spotify para gerenciar os tokens e eu confio no aplicativo Spotify para não perder os tokens.

Quando o token de acesso expira (normalmente, em uma a duas horas), o Spotify pode usar o token de atualização para obter um novo.

O token de atualização dura meses. Dessa forma, eu só tenho que fazer login no meu telefone algumas vezes por ano. A desvantagem é que, se eu perder esse token de atualização, outra pessoa poderá usar minha conta por meses. O token de atualização é tão importante que o iOS fornece um chaveiro para tokens, onde garante criptografá-los e armazená-los com segurança.

O uso do OAuth2 em um aplicativo da Web funciona da mesma maneira. Em vez de usar uma visualização da Web, você pode abrir a solicitação de login do OAuth2 em um quadro, um iframe ou uma janela separada. Você também pode abri-lo na página atual, mas isso faria com que você perdesse todo o estado do aplicativo JavaScript sempre que alguém precisasse fazer login.

Quando entro no Quora com meu navegador da web, não recebo um token de atualização. Eles querem que o token expire e me avise para fazer login novamente quando eu sair do meu navegador ou até mesmo sair para almoçar. Clientes não confiáveis ​​não podem atualizar o token porque não podem ser confiáveis ​​para manter o token de atualização importante. É mais seguro, mas menos conveniente, porque eles solicitarão que você faça login novamente com muito mais frequência.

Usando OAuth2 em seu aplicativo

Agora você sabe como o OAuth2 funciona, mas provavelmente não deseja implementar seu próprio cliente OAuth2. Você pode ler toda a especificação OAuth 2.0 de 75 páginas se estiver com problemas para dormir, mas não precisa. Algumas ótimas bibliotecas estão disponíveis para você usar.

O iOS tem suporte integrado para OAuth2. Corrina Krych tem um tutorial muito útil sobre como usar o OAuth 2.0 com Swift. Ele explica como obter um token, como integrar as visualizações em seu aplicativo e onde armazenar seus tokens.

O Android também tem suporte integrado para OAuth2. Devo admitir que não estou tão familiarizado com isso porque me concentro no iOS, mas há algumas boas seções na documentação para mostrar exemplos e algumas bibliotecas de código aberto para facilitar ainda mais.

JavaScript não tem suporte interno para OAuth2, mas há clientes para todas as principais bibliotecas JavaScript. O React é totalmente compatível com OAuth2. AngularJS tem suporte de terceiros para OAuth2.0 para muitos projetos. Eu até escrevi um deles.

Depois de ter um cliente OAuth2, você precisará escolher um provedor.

Em quem você confia?

A grande suposição aqui é que eu confio mais no Facebook do que no Spotify. Não tenho uma boa razão para isso. O Facebook não torna pública sua segurança interna e não há uma boa maneira de auditá-la. O Spotify também não. Não há relatórios do consumidor para segurança OAuth2. Estou basicamente confiando no Facebook porque é maior. Eu confio no Facebook porque outras pessoas confiam.

Também confio mais no Facebook cada vez que clico no botão “Log in with Facebook”. Se o Facebook perder minha senha, os hackers terão acesso não apenas à minha conta do Facebook, mas também à minha conta do Spotify e a qualquer outro serviço que eu tenha conectado com minha conta do Facebook. A vantagem é que há apenas um lugar onde eu tenho que redefinir minha senha para corrigir o problema.

Não tenho que confiar no Facebook, mas tenho que confiar em alguém. Alguém tem que me autenticar. Preciso escolher o provedor em que confio.

Escolhendo um provedor OAuth2

A Wikipedia mantém uma lista de provedores OAuth, mas você não se importaria com a maioria deles. Os grandes são Facebook e Google. Você também pode querer olhar para a Amazon ou Microsoft.

Todos os quatro são grandes e fáceis de integrar. O Facebook fornece instruções para registrar um aplicativo. O Google tem etapas semelhantes. A ideia básica é que você crie uma conta de desenvolvedor e, em seguida, crie um ID de aplicativo. O provedor fornece um ID de cliente que você pode usar para fazer solicitações.

Você também pode escolher vários provedores. O Quora permite que você faça login com Facebook ou Google; porque ambos usam OAuth2, você pode usar o mesmo código para ambos.

O que está faltando no OAuth2

OAuth2 faz um trabalho muito bom para resolver um problema complexo, mas está faltando algumas coisas:

• O padrão não é completamente padrão. Nunca consegui escrever um único cliente OAuth2 que possa fazer login no Facebook e no Google sem algumas instruções if . Cada um interpreta a especificação de forma diferente, e há poucos detalhes diferentes para cada um. Eles também sempre têm ideias diferentes sobre quais escopos fornecer. Usar uma biblioteca para integração com OAuth2 ajuda muito nesse problema, mas nunca será 100% transparente no código do seu app.
• Sair é complicado. . Todo aplicativo ou site que usa OAuth2 tem um botão de logout, mas a maioria simplesmente esquece os tokens sem invalidá-los. O aplicativo esquecerá todos os seus tokens atuais e permitirá que outra pessoa faça login, mas seus tokens ainda são válidos. Se um hacker roubasse seu token, ele ainda poderia usá-lo e fazer login como você.

Há uma especificação separada para invalidar tokens OAuth2, mas ela não foi escolhida por muitos dos principais provedores. OAuth2 não fornece uma forma de recuperação se um hacker obtiver seu token de atualização; mesmo que você possa excluir sua cópia local do token, o hacker ainda o terá. Muitos provedores oferecem uma maneira de suspender sua conta, mas não há uma maneira padrão de fazer isso.

Em defesa do OAuth2, esse é um problema difícil, porque muitos provedores usam criptografia de chave pública para criar tokens sem estado. Isso significa que o servidor não se lembra dos tokens que criou, portanto, não pode esquecê-los mais tarde.

O outro grande problema com o OAuth2 é que você depende do seu provedor. Quando o Facebook cai, o mesmo acontece com o botão “Fazer login com o Facebook” em seu aplicativo. Se o Google decidir começar a cobrar pelo suporte ao OAuth2 ou exigir que você compartilhe seus lucros com ele, não há nada que você possa fazer. Esta é a faca de dois gumes de confiar em um provedor: eles estão fazendo muito por você, mas têm controle sobre seus usuários.

OAuth2 executa o mundo

Mesmo com alguns recursos ausentes e uma grande dependência, o OAuth2 ainda é uma excelente escolha. Isso torna mais fácil para os usuários fazerem login em seu aplicativo, não precisarem lembrar uma senha para cada site e confiarem em sua segurança. OAuth2 é uma escolha muito popular. Domina a indústria. Nenhum outro protocolo de segurança chega perto da adoção do OAuth2.

Agora você sabe de onde vem o OAuth2 e como ele funciona. Faça escolhas inteligentes sobre em quem confiar, pare de ler artigos sobre como armazenar senhas criptografadas com segurança e passe mais tempo escrevendo seu aplicativo incrível.