Já falamos que você nunca deve passar suas senhas para outras pessoas. Quando um site deseja usar os serviços de outro, como a publicação do Bitly no seu stream do Twitter, em vez de solicitar que você compartilhe sua senha, ele deve usar um protocolo chamado OAuth.
É importante entender como um programa, site ou aplicativo pode autenticar você como usuário. Ele tem as permissões certas? Você concedeu algum tipo de maneira de verificar quem você é e acessar dados em seu nome? O OAuth ajuda a simplificar esse processo: mas mesmo com a automação, você deve sempre estar ciente de como uma pessoa ou empresa usa (ou armazena) seus dados.
Receba gratuitamente o guia básico de conformidade e regulamentação da proteção de dados nos EUA.
O que é o OAuth?
O OAuth é um protocolo ou estrutura de autorização de padrão aberto que fornece aos aplicativos a capacidade de “acesso designado seguro”. Você pode, por exemplo, dizer ao Facebook que a ESPN.com pode acessar seu perfil ou postar atualizações em sua linha do tempo sem precisar fornecer à ESPN sua senha do Facebook. Isso minimiza o risco de forma importante: caso a ESPN sofra uma violação, sua senha do Facebook permanece segura.
O OAuth não compartilha dados de senha, mas usa tokens de autorização para provar uma identidade entre consumidores e provedores de serviços. O OAuth é um protocolo de autenticação que permite que você aprove um aplicativo interagindo com outro em seu nome sem fornecer sua senha.
SAML x OAuth
O SAML (Security Assertion Markup Language) é um padrão alternativo de autenticação federada que muitas empresas usam para logon único (SSO). O SAML permite que as empresas monitorem quem tem acesso aos recursos corporativos.
Existem muitas diferenças entre o SAML e o OAuth. O SAML usa XML para transmitir mensagens, já o OAuth usa JSON. O OAuth oferece uma experiência mais simples em dispositivos móveis, enquanto o foco do SAML é a segurança corporativa. Esse último ponto é um diferencial importante: o OAuth usa chamadas de API extensivamente, e é por isso que aplicativos móveis, aplicações da web modernas, consoles de jogos e dispositivos de Internet das Coisas (IoT) consideram o OAuth uma experiência melhor para o usuário. O SAML, por outro lado, baixa sessão de cookies em um navegador que permite ao usuário acessar determinadas páginas da web, o que é ótimo para dias de trabalho curtos, mas não tão bom quando é necessário fazer login utilizando essa ferramenta todos os dias.
Exemplo de OAuth
O exemplo mais simples de OAuth em ação é um site que diz “ei, você quer entrar em nosso site com o login de outro site?”. Nesse cenário, a única coisa que o primeiro site — vamos nos referir a ele como consumidor — quer saber é que o usuário é o mesmo em ambos os sites e fez login com sucesso no provedor de serviços, que é o site em que o usuário fez login inicialmente, não o consumidor.
Os aplicativos do Facebook são um bom exemplo de caso de uso do OAuth. Digamos que você esteja usando um aplicativo no Facebook e ele peça para você compartilhar seu perfil e suas fotos. O Facebook é, nesse caso, o provedor de serviços: ele tem seus dados de login e suas fotos. O aplicativo é o consumidor e, como usuário, você deseja usá-lo para fazer algo com suas fotos. Você deu especificamente a esse aplicativo acesso às suas fotos, que o OAuth está gerenciando em segundo plano.
Seus dispositivos domésticos inteligentes, como torradeira, termostato, sistema de segurança, etc., provavelmente usam algum tipo de dados de login para sincronizar uns com os outros e permitir que você os administre a partir de um navegador ou dispositivo cliente. Esses dispositivos usam o que o OAuth chama de autorização confidencial. Isso significa que eles mantêm as informações da chave secreta, para que você não precise fazer login várias vezes.
Explicação sobre o OAuth
O OAuth tem a ver com autorização, não autenticação. Autorização é pedir permissão para tomar algumas ações. Autenticação é provar que você é a pessoa correta porque sabe das coisas. O OAuth não transmite dados de autenticação entre consumidores e provedores de serviços, mas atua como uma espécie de token de autorização.
A analogia comum que vi ser usada ao pesquisar o OAuth é a chave do manobrista do seu carro. A chave do manobrista permite que o manobrista dê partida e ande com o carro, mas não dá acesso ao porta-malas ou ao porta-luvas.
Um token OAuth é como essa chave de manobrista. Como usuário, você pode dizer aos consumidores o que eles podem usar e o que não podem usar de cada provedor de serviços. Você pode dar a cada consumidor uma chave de manobrista diferente. Eles nunca têm a chave completa ou qualquer um dos dados privados que dá acesso à chave completa.
Como o OAuth funciona
Existem três agentes principais em uma transação OAuth: o usuário, o consumidor e o provedor de serviços. Esse trio foi carinhosamente apelidado de “Triângulo Amoroso OAuth”.
No nosso exemplo, Joe é o usuário, Bitly é o consumidor e o Twitter é o serviço fornecido que controla o recurso seguro do Joe (seu stream do Twitter). O Joe quer autorizar o Bitly a publicar links curtos em seu stream. Veja como funciona:
Etapa 1 – O usuário mostra a intenção
- Joe (Usuário): “Ei, Bitly, eu quero que você publique links diretamente no meu stream do Twitter.”
- Bitly (Consumidor): “Bacana! Vou pedir permissão.”
Etapa 2 – O consumidor obtém permissão
- Bitly: “Tenho um usuário que gostaria que eu publicasse em seu stream. Você pode me mandar um token de solicitação?”
- Twitter (provedor de serviços): “Claro! Aqui está um token e um segredo.”
O segredo é usado para evitar falsificação de pedidos. O consumidor usa o segredo para assinar cada solicitação para que o provedor de serviços possa verificar se ela está realmente vindo do aplicativo do consumidor.
Etapa 3 – O usuário é redirecionado para o provedor de serviços
- Bitly: “Pronto, Joe. Estou redirecionando você para o Twitter para você aprovar. Leve este token com você.”
- Joe: “Certo!”
- O Bitly direciona o Joe para o Twitter para a autorização>
Esta é a parte assustadora. Se o Bitly fosse o tenebroso Evil Co., ele poderia abrir uma janela parecida com o Twitter para pegar seu nome de usuário e senha, mas na verdade seria um phishing. Sempre verifique se o URL para o qual você é direcionado é realmente o provedor de serviços (Twitter, nesse caso).
Etapa 4 – O consumidor obtém permissão
- Joe: “Twitter, eu gostaria de autorizar este token de solicitação que o Bitly me deu.”
- Twitter: “Certo. Só para ter certeza, você quer autorizar o Bitly a fazer X, Y e Z com sua conta do Twitter?”
- Joe: “Isso mesmo!”
- Twitter: “Beleza. Então você pode voltar ao Bitly e dizer que ele tem permissão para usar o token de solicitação.”
O Twitter marca o token de solicitação como “autorizado”. Assim, quando o consumidor solicita acesso, ele será aceito (desde que seja assinado usando seu segredo compartilhado).
Etapa 5 – O consumidor obtém um token de acesso
- Bitly: “Twitter, posso trocar esse token de solicitação por um token de acesso?”
- Twitter: “Claro. Aqui está o seu token de acesso e o segredo.”
Etapa 6 – O consumidor acessa o recurso protegido
- Bitly: “Eu gostaria de publicar este link no stream do Joe. Este é meu token de acesso.”
- Twitter: “Pronto!”
No nosso cenário, o Joe nunca precisou compartilhar as credenciais do Twitter dele com o Bitly. Ele simplesmente delegou o acesso usando o OAuth de maneira segura. A qualquer momento, o Joe pode fazer login no Twitter e revisar o acesso que concedeu e revogar tokens para aplicativos específicos sem afetar outros. O OAuth também permite níveis de permissão detalhados. Você pode dar ao Bitly o direito de publicar na sua conta do Twitter, mas restringir o LinkedIn ao acesso somente leitura.
OAuth 1.0 x OAuth 2.0
O OAuth 2.0 é uma reformulação completa do OAuth 1.0 e os dois não são compatíveis. Se você criar um novo aplicativo hoje, use o OAuth 2.0. Este blog só se aplica ao OAuth 2.0, já que o OAuth 1.0 está obsoleto.
O OAuth 2.0 é mais rápido e fácil de implementar. O OAuth 1.0 usava requisitos criptográficos complicados, era compatível com apenas três fluxos e não apresentava capacidade de expansão.
O OAuth 2.0, por outro lado, tem seis fluxos para diferentes tipos de aplicações e requisitos e permite segredos assinados por HTTPS. Os tokens OAuth não precisam mais ser criptografados nos endpoints na versão 2.0, pois são criptografados em trânsito.
Outros recursos
Esperamos que essa tenha sido uma boa introdução para você se familiarizar com o OAuth. Assim, da próxima vez que você se deparar com “Fazer login com o Twitter” ou uma verificação de identidade delegada parecida, você terá uma boa ideia do que está acontecendo.
Se quiser saber mais sobre a mecânica do OAuth, aqui estão alguns links úteis:
