Nós vivemos e respiramos OAuth então acredito que podemos escrever uma introdução simples ao OAuth, que seja de alta qualidade e ainda assim técnica o suficiente para ser útil para investidores, gerentes e engenheiros. Pronto? Apertem os cintos para essa jornada. E se não fizermos um bom trabalho, avise-nos no final.
Nota: Estamos falando sobre OAuth2, mas usamos o termo OAuth.
O que é OAuth?
OAuth é um protocolo que permite que um web service peça permissão ao usuário para realizar algo em seu nome, frequentemente com o objetivo de tornar a vida mais conveniente.
Por exemplo, um web service que tenha o botão de “Login com Facebook” está na verdade pedindo que o usuário dê permissão para ler o perfil, assim o perfil pode ser copiado do Facebook para o web service, sem que o usuário tenha que inserir vários detalhes.
Como que OAuth é diferente de outros protocolos de autorização?
A maioria dos protocolos de autorização tem uma abordagem centralizada; como um servidor implementando o protocolo você decide quem (parceiros, desenvolvedores, etc) podem realizar uma ação, e qual ação (escopo de permissão, por exemplo, ler perfil, baixar arquivo, etc) podem ser realizados.
OAuth, por outro lado, implementa autorização delegada; cada usuário no provedor de OAuth é delegado a autoridade de decidir quem pode realizar uma ação em seu nome e qual ação pode ser realizada.
Quais são os envolvidos no OAuth?
Há 3 partes envolvidas:
- Web service – deseja realizar algo em nome do usuário, por exemplo, ler o perfil;
- Provedor OAuth – caso onde o usuário tem uma conta de Facebook, por exemplo, e somente o provedor OAuth sabe como autenticar, por exemplo, verificar quem a pessoa é através de nome e senha, autenticação de dois fatores (2FA), biometria, etc;
- Usuário – Deseja usar o web service e está disposto a dar permissão ao web service para se comunicar com sua conta no provedor OAuth, por exemplo, permitir que o web service leia seu perfil no provedor OAuth.
Como é o fluxo do OAuth?
Há 4 fluxos diferentes de OAuth, cada um para um caso de uso específico, o que não vamos falar aqui.
No entanto, todos os 4 compartilham o mesmo fluxo de alto nível, em 2 passos:
1. O web service, usuário e provedor OAuth interagem e o resultado é que o web service adquire um token de acesso digital englobando a identidade de usuário (autenticação) e permissões (autorização).
2. O web service apresenta o token de acesso digital para qualquer serviço que confie no provedor OAuth, para que o web service realize a ação permitida em nome do usuário.
Para todos os 4 fluxos OAuth a parte 2 é idêntica. No entanto, a maneira que o web service, usuário e provedor OAuth interagem na parte 1 para gerar o token de acesso digital é diferente, mas não falaremos disso aqui, confira uma comparação do fluxo do diagrama aqui.
Quando preciso de OAuth?
Você pode usar OAuth como consumidor, provedor ou entidade federal.
Já falamos sobre usar OAuth como consumidor, aqui vai uma recapitulação: você é um web service que deseja acessar alguns dados de usuário que estão em outro web service ou executar algo em outro serviço em nome do usuário, e o serviço implementa o controle de acesso usando OAuth, o que demanda que o usuário dê permissão na forma de token de acesso digital.
Como provedor, você é um web service que tem muitos usuários e dados, e deseja aumentar o valor de sua plataforma ao dar poder a desenvolvedores do mundo todo para criar aplicações para seus usuários ao utilizar os dados deles através de API endpoints usando protocolo OAuth.
Como entidade federativa, você deseja implementar Single-Sign On (SSO) onde a autenticação é feita somente uma vez por um provedor OAuth centralizado, com o resultado sendo um token digital que engloba identidade de usuário e permissões, que podem ser apresentados para qualquer grupo de serviços que confiem no provedor OAuth para ganhar acesso.
Conclusão
Agora você pode usar OAuth como um profissional! Caso contrário, queremos ouvir de você onde deixamos a desejar nessa introdução.
Se você não quiser lidar com a complexidade OAuth e preferir usar OAuth como um web service sem fazer muito esforço, ou se tornar um provedor OAuth como uma plataforma, ou usar OAuth para Single-Sign On (SSO), agende um chat, mande um email ou marque uma conversa com os especialistas da OAuth.io
