O que é o protocolo OAuth?

Com a vida moderna dependendo cada vez mais de contas em diferentes serviços digitais, a possibilidade de acessar os serviços a partir de uma única credencial é algo que atrai muitos usuários. O que muita gente não sabe é que esse processo é feito a partir de um protocolo específico, chamado de OAuth 2 — que, claro, é a evolução do OAuth.

• O que é permalink?
• O que é ransomware? Aprenda tudo sobre a ameaça e como removê-la
• O que é engenharia social? Veja como evitar problemas de segurança

Provavelmente você já clicou em algum botão escrito “Logar com sua conta do Google” ou “Logar com sua conta do Facebook” quando você está em algum site , para evitar ter que realizar um novo cadastro com senha e afins em um serviço. Neste caso, você está dando a autorização de uma aplicação de terceiros a usar os recursos de suas contas no Google ou o Facebook como credenciais. Isso constitui o protocolo OAuth 2.

O Auth 2 é um protocolo de autorização que permite que uma aplicação se autentique em outra, como visto no exemplo acima. É importante frisar que o protocolo da acesso limitado a essas aplicações, só para permitir a autenticação dos usuários. Esse protocolo é utilizado nos mais diversos tipos de autenticação, como em telas de login e na autenticação de Application Programming Interface (APIs, em inglês).

Um dos diferenciais desse método, além de permitir que usuários acessem contas sem precisar de credencial específicas para aquele serviço, é que depois que uma permissão é cedida, mesmo que o usuário troque a senha do aplicativo, ele poderá continuar usando com aquele serviço, sem precisar de uma nova autenticação. Do mesmo jeito, as permissões podem ser revogadas a qualquer momento.

Diferenças entre OAuth 1 e OAuth 2 

Porém, como o número após o nome do protocolo indica, OAuth 2 não é a primeira versão desse sistema. OAuth 1.0 foi criado em novembro de 2006, e não é compatível com a segunda versão do protocolo, disponibilizada em 2012.

Embora suas funções sejam semelhantes, existe uma série de diferenças fundamentais entre as duas versões. Listamos elas abaixo:

• Menos necessidade de usar aplicativos de terceiros na autenticação: No OAuth 1.0, aplicativos de desktop ou de celular precisavam direcionar o usuário a abrir o navegador para o serviço desejado, autenticar com o serviço e copiar o token do serviço de volta para o aplicativo. Com o OAuth 2.0, agora existem novas maneiras de um aplicativo obter autorização para um usuário, sem necessidade de abertura de aplicativos externos;
• Disponíbilidade em aplicativos sem criptografia: O OAuth 2.0 não exige mais que os aplicativos clientes tenham criptografia, permitindo que solicitações sejam feitas apenas com o token emitido por HTTPS, diferente da primeira versão, que necessitava de processos de criptografia do token antes de seu uso;
• Assinaturas menos complexas: As assinaturas do OAuth 2.0 são muito menos complicadas, não necessitando de análise, classificação ou codificação especial. A primeira versão contava com todas essas complicações, fazendo com que muitos serviços não a adotassem por insegurança quanto ao processo de implementação do protocolo;
• Melhor separação de funções: por fim, o OAuth 2.0 tem separação clara de funções entre o servidor responsável pelo tratamento de solicitações do OAuth e o servidor responsável pela autorização do usuário, deixando o fluxo de dados mais organizado. Na primeira versão, tudo era feito junto, complicando vários processos.

Como funciona?

O protocolo OAuth 2 atua em cima de 4 papéis, onde cada um deles tem uma missão própria na autenticação do protocolo. Os 4 papéis são:

• Dono do Recurso: pessoa ou entidade que concede o acesso aos seus dados. Também chamado de dono do recurso.
• Cliente: é a aplicação que interage com o Resource Owner, como por exemplo o browser, falando no caso de uma aplicação web. Ele é classificado de duas formas: Cliente Confidencial, que é capaz de manter a confidencialidade das credencias; e Cliente Público, que não consegue manter a confidencialidade delas;
• Servidor de Recurso: a API que está exposta na internet e precisa de proteção dos dados. Para conseguir acesso ao seu conteúdo é necessário um token que é emitido pelo authorization server.
• Servidor de Autenticação: responsável por autenticar o usuário e emitir os tokens de acesso. É ele que possui as informações do resource owner (o usuário), autentica e interage com o usuário após a identificação do client.

Esses quatro papéis desempenham funções importantes em todo o fluxo de autenticação do protocolo, que listamos a seguir:

1. O Cliente pede autorização ao Dono do Recurso para acessar seus recursos;
2. Caso o Dono do Recurso tenha autorizado o acesso, o Cliente recebe uma garantia de autorização. Essa credencial representa a autorização concedida pelo Resource Owner;
3. O Cliente pede um token de acesso ao Servidor de Autenticação, enviando a garantia de autorização;
4. Assumindo que o Cliente foi autorizado com sucesso e que a garantia de autorização é válida, o Servidor de Autenticação gera um token de acesso e o envia ao Cliente;
5. O Cliente pede acesso a um recurso protegido pelo Servidor de Recursos, e se autentica com o token de acesso;
6. Assumindo que o token seja válido, o Servidor de Recursos responde à requisição do Cliente servindo o recurso solicitado, permitindo agora que o usuário tenha acesso ao serviço.

A garantia de autorização, citado no segundo passo do fluxo, também conta com algumas variações, que definem como será feito o processo de autenticação. Elas são as seguintes:

• Implícita: utilizado para clientes web, ou seja, que são acessados por navegadores. Essa garantia de autorização só é válida para o usuário, e não para o cliente como um todo;
• Código de Autenticação: obtido usando um servidor de autenticação como intermediário entre o cliente e o usuário, em situações onde as aplicações pedindo permissão não são confiáveis;
• Credenciais de senha do Dono doRecurso: utilizado quando o cliente solicita o usuário e senha diretamente, esse já utilizado em aplicações chamadas de confiáveis, como aplicações da própria empresa;
• Credenciais de cliente: pode ser utilizado quando a aplicação cliente é protegida ou utilizada em integrações de sistemas.
  

Embora aparente ser complexo, o protocolo OAuth 2 já está presente no nosso dia a dia e, quando o usamos, nem percebemos que todos esses passos estão sendo executados. No fim, ele é mais uma forma de facilitar a vida virtual das pessoas.

Fonte: TreinaWeb, Hueniverse