Entendendo o padrão oAuth 2.0

Alexandre Malavasi
Training Center
Published in
7 min readDec 27, 2017

Com o aumento exponencial da utilização de redes sociais, como Facebook e Twitter, tornou-se muito comum a integração de aplicativos e sistemas com estas novas plataformas de mídias sociais, permitindo que o usuário informe dados de autenticação de sua rede social preferida para se logar em diversos aplicativos e sites ao invés de ter que criar uma nova senha específica para o acesso e ter que memorizar mais uma das muitas senhas que permeiam o seu dia a dia.

Ao mesmo tempo que este tipo de autenticação por redes sociais começou a se popularizar e ser utilizado largamente por empresas e desenvolvedores de sistemas, surgiu a grande preocupação dos usuários em relação ao sigilo e confidencialidade de informações pessoais e credenciais de acesso às suas redes sociais, havendo interesse de proteger ao máximo suas informações pessoais a todo custo e manter sua privacidade.

Fonte: http://blog.cybertraining365.com

Na maioria dos usuários pairavam dúvidas a respeito da segurança deste tipo de autenticação por redes sociais, gerando este tipo de questionamento, que é sempre muito bem-vindo:

“Será que o administrador ou desenvolvedor deste site terá acesso ao meu Facebook se eu utilizar o login pelo Facebook?”

Essas e outras preocupações eram reais (e muito pertinentes diga-se de passagem). Com o grande compartilhamento e divulgação de informações pessoais nas redes sociais, a exigência de garantia de sigilo e confidencialidade das informações pessoais foi aumentando proporcionalmente ao número de usuários e aplicativos que realizavam integração com estas redes sociais.

Dito isto, onde entra o padrão oAuth 2.0 nesta história toda?

Origem

O padrão oAuth surgiu, não de forma proposital e de forma não oficial, no ano de 2006 quando Blaine Cook, na época líder da equipe de desenvolvimento do Twitter, estava tentando estabelecer um padrão de autenticação que tivesse um uso mais universal, criando o OpenID. Após identificar problemas e limitações com o OpenID, ele se juntou com alguns profissionais como Chris Messina, David Recordon, Larry Halff, dentre outros e, de forma conjunta, chegaram à conclusão de que um padrão aberto de autenticação precisava ser definido e criado para ser utilizado na indústria de desenvolvimento de software em larga escala, provendo-se de boas práticas de segurança já existentes no mercado. Após intensos debates e contribuições diversas, chegou-se na especificação inicial de um novo padrão de autenticação, nascendo assim o OAuth Core 1.0.

Propósito

O padrão oAuth foi criado para se preservar dados sensíveis de autenticação (usuário e senha) e dados atrelados ao usuário sob os quais estas credenciais teriam direito de acesso. Em outras palavras, o usuário deve ter o direito de se autenticar em sites e aplicativos de forma segura e integrada, mas controlando detalhadamente as permissões que ele deseja que o site possua em relação aos seus dados. Ficou confuso ou muito vago? Então vamos dar um exemplo mais realístico.

Quando nós estamos na fila de embarque em um aeroporto, é necessário que nos identifiquemos junto ao comissário de bordo, que fará a checagem entre um documento de identificação fornecido por nós e os dados de cartão de embarque. Quando entregamos nosso documento ao funcionário da companhia aérea não ficamos preocupados em relação à segurança das nossas informações pessoais ou perda de sigilo, pois é de senso comum que a entrega do documento tem um único propósito, que é o de identificar, se restringindo somente a isto. Não há necessidade do comissário de bordo saber onde você mora, quanto tem na sua conta bancária, qual o nome do seu cachorro e por aí vai. Ele só saberá se VOCÊ PERMITIR e contar ao funcionário, voluntariamente.

E é exatamente assim que funciona o padrão oAuth. Fornecemos nossas credenciais de acesso ao site/serviço autenticador (Facebook, Twitter, Google, etc) e, caso essas credenciais sejam válidas, somos redirecionados para uma tela que permite ao mesmo validar quais tipos de informação ele deseja compartilhar com o site ou aplicativo que ele está acessando. Logo após estas permissões serem concedidas, o acesso é feito a partir de um token fornecido pelo “aplicativo autenticador”, que pode ser o Facebook, Twitter ou qualquer outro serviço que disponibilize uma API que permita autenticações neste padrão.

A imagem abaixo, extraída do site SmartBear, exemplica muito bem o fluxo de autenticação do padrão oAuth 2.0:

Baseado no que já tratamos resumidamente e de forma simples sobre o padrão, podemos elencar os seguintes passos, tomando-se como exemplo autenticação por redes sociais:

  1. O usuário acessa um site ou aplicativo específico desejando se autenticar (vamos chamar este site ou aplicativo de “client” daqui pra frente)
  2. O “client” disponibiliza formas e opções de autenticação como, por exemplo, pelo Facebook ou Google.
  3. O usuário é redirecionado para a tela de login da rede social escolhida.
  4. Após informar usuário e senha da rede social, casos as credenciais estejam corretas, a rede social fornece um token ao “client”, legitimando o acesso do usuário.
  5. Caso o acesso por este meio de autenticação seja realizado pela primeira vez através da aplicação “client” e ela deseje utilizar alguma informação de cunho pessoal do usuário, o mesmo é redirecionado para uma tela de permissões a fim de que o usuário especifique quais dados ele permite compartilhar com o site ou aplicação “client”: e-mail, nome completo, etc.
  6. Por último, o acesso do usuário é realizado normalmente, permitindo a navegação em área privada do site ou aplicativo “client”, de forma identificada e autorizada, sempre sendo utilizado o token de autenticação fornecido pela rede social, sendo validado por ela quanto à validade e políticas específicas previamente definidas.

Para facilitar ainda mais a compreensão, vou citar um exemplo recém-feito por mim como usuário no site do New York Times. Ao clicar em “Log In” no canto superior direito, fui redirecionado para a tela de login com opções de autenticação, sendo o “segundo passo” citado na nossa listagem:

Tela de login do New York Times

Ao escolher a opção de login pelo Google, fui redirecionado para uma tela de login do próprio serviço de autenticação da Google (vide URL na imagem abaixo). Sendo assim, não estou fornecendo meus dados de autenticação(usuário e senha) da minha conta do Google ao New York Times e sim ao próprio Google. Então, sem problemas. Este é o “passo três”.

Após fornecer meus dados de autenticação, como nunca tinha me logado no New York Times com a minha conta do Google, fui redirecionado para uma tela da aplicação “client”, com informações específicas e termos para aceitação. Poderia ser perfeitamente uma tela do próprio Google solicitando minha autorização para que o New York Times tivesse acesso aos meus dados pessoais, como nome completo, por exemplo. Como a aplicação “client” neste caso não necessitava de informações de identificação adicionais, esta tela de permissões não foi necessária. É importante frisar aqui que o serviço de autenticação do Google, após eu ter informado as minhas credenciais válidas, devolveu um token à aplicação “client” permitindo o acesso.

É importante notar também que, a partir deste momento, a continuidade do acesso dá-se na aplicação “client” (vide URL), não estando mais nas páginas de login ou servidores do Google. O acesso neste momento já foi concedido e autorizado via oAuth e, em cada navegação que eu fizer nesta sessão na área restrita no site do New York Times, cabe à aplicação “client” (o próprio site do New York Times) enviar o token de acesso gerado pelo Google ao próprio Google para verificar se o meu acesso continua válido. Esta operação, embora pareça repetitiva e complexa, normalmente é feita de forma muito simples por intermédio de API’s e SDK’s disponibilizados pelas próprias redes sociais, que se utilizam de dados em formato JSON, podendo ser facilmente manipuláveis pela maioria das linguagens de programação modernas.

Como exemplo da implementação e utilização de oAuth no .NET com C#, há vários exemplos práticos interessantes já implementados e compartilhados pela comunidade. Particularmente, achei bastante interessante este projeto disponível no Github, que possui exemplos com diversos serviços de autenticação oAuth 2.0:

Acho também que, dada a extensão e profundidade que este tema pode ter e considerando que este artigo abordou o assunto de forma apenas básica e introdutória, cabe a realização de mais alguns artigos abordando este tema.

Muito obrigado por ter lido este artigo até o final. Fico aberto à sugestões de melhoria e contribuições, pois estamos todos em fase de constante aprendizado e buscando aprimoramento.

Aprender e dominar este padrão de autenticação hoje em dia tornou-se quase obrigação para nós desenvolvedores.

Um grande abraço.

Referências

Linkedin: https://www.linkedin.com/in/alexandremalavasi

Meu Livro

Fico muito feliz em anunciar que tive a felicidade de escrever meu primeiro livro. É um conteúdo muito bem detalhado sobre Design Patterns, orientação a objeto, princípios SOLID, .NET 5 e C# no geral. Você pode adquirir o livro no link abaixo:

--

--

Alexandre Malavasi
Training Center

Microsoft MVP | MCP | MCTS | MCPD | ITIL | .NET | MBA | MTAC | Technical Leader | Consultant | .NET Developer