quarta-feira, 29 de setembro de 2021

O que é o protocolo OAuth?

Com a vida moderna moderna cada vez mais de contas em serviços digitais, uma possibilidade de acesso aos 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.


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 que realizar um novo cadastro com senha e afins em um serviço. Neste caso, você está dando permissã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 de acesso limitado a essas aplicações, só para permitir uma autenticação dos usuários. Esse protocolo é utilizado nos mais diversos tipos de autenticação, como em telas de login e autenticação de Application Programming Interface (APIs, em inglês).  

Um dos diferenciais desse método, além de permitir que os usuários acessem contas sem precisar de credencial específico para aquele serviço, é que depois que uma permissão é cedida, mesmo que o usuário troque a senha do aplicativo, ele pode continuar usando com aquele serviço, sem precisa de uma nova autenticação. Faça mesmo jeito, pois 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 : Não OAuth 1.0, aplicativos de desktop ou de celular precisavam direcionar o usuário para 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 obter um aplicativo necessário, se houver 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 sejam feitas apenas com o token emitido por HTTPS, diferente da versão, que necessitava de processos de criptografia 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 classificaçã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 de funções entre o servidor responsável pelo tratamento de execução de OAuth e o servidor responsável pela permissão do usuário, permissão de 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 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 : uma 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 servidor de permissão.
  •  Servidor de Autenticação : responsável por autenticar o usuário e emitir 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.

  • Ilustração demonstrando o fluxo de permissão.
    (Imagem: Reprodução / TreinaWeb)

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 permissão ao Dono do Recurso para acessar seus recursos;
  2. Caso o Dono do Recurso tenha autorizado o acesso, o Cliente receba uma garantia de permissão. Essa credencial representante autorizada concedida pelo Resource Owner;
  3. O Cliente pede um token de acesso ao Servidor de Autenticação, enviando uma garantia de permissã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 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.

Uma garantia de permissão, citado no segundo passo do fluxo, também contém algumas modificações, que definem como 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 permissão é válida para o usuário, e não para o cliente como um todo;
  •  Código de Autenticação : usar um servidor de autenticação como intermediário entre o cliente e o usuário, em situações onde as solicitações solicitadas não são permitidas;
  •  Credenciais de senha do Dono do  Recurso utilizado:  quando o cliente solicitação o usuário e senha diretamente, esse já utilizado em chamadas de aprendizagem, como aplicações da própria empresa;
  •  Credenciais de cliente : pode ser utilizado quando um aplicativo cliente é protegido ou utilizado em integrações de sistemas.

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

                                                                           CANALTECH

0 comentários: