Mercado abrirá em 9 h 54 min
  • BOVESPA

    106.363,10
    -56,43 (-0,05%)
     
  • MERVAL

    38.390,84
    +233,89 (+0,61%)
     
  • MXX

    51.714,60
    -491,99 (-0,94%)
     
  • PETROLEO CRU

    81,09
    -1,57 (-1,90%)
     
  • OURO

    1.799,50
    +0,70 (+0,04%)
     
  • BTC-USD

    58.822,05
    -1.746,28 (-2,88%)
     
  • CMC Crypto 200

    1.410,34
    -63,99 (-4,34%)
     
  • S&P500

    4.551,68
    -23,11 (-0,51%)
     
  • DOW JONES

    35.490,69
    -266,19 (-0,74%)
     
  • FTSE

    7.253,27
    -24,35 (-0,33%)
     
  • HANG SENG

    25.670,87
    +42,13 (+0,16%)
     
  • NIKKEI

    28.844,14
    -254,10 (-0,87%)
     
  • NASDAQ

    15.618,25
    +31,00 (+0,20%)
     
  • BATS 1000 Index

    0,0000
    0,0000 (0,00%)
     
  • EURO/R$

    6,4203
    -0,0044 (-0,07%)
     

O que é o protocolo OAuth?

·5 minuto de leitura

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.

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.

<em>Ilustração demonstrando o fluxo do processo de autorização. (Imagem: Reprodução/TreinaWeb)</em>
Ilustração demonstrando o fluxo do processo de autorizaçã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 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 do Recurso: 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: Canaltech

Trending no Canaltech:

Nosso objetivo é criar um lugar seguro e atraente onde usuários possam se conectar uns com os outros baseados em interesses e paixões. Para melhorar a experiência de participantes da comunidade, estamos suspendendo temporariamente os comentários de artigos