OAuth 2.0: o que é e como aplicar o mais conhecido protocolo de autorização em sua aplicação

Você sabe o que é e como utilizar o Protocolo de Autorização OAuth 2.0? Tentarei resumir neste artigo de forma simples o que conheço e espero que te ajude.

O Protocolo

O OAuth é uma camada de autenticação entre a aplicação terceira (client), a proprietária dos recursos (resource owner) e o controlador destes recursos (resource server) onde o usuário consente com a liberação de acesso a dados limitados, que estão hospedados no controlador de tais recursos.

Ele foi criado para garantir a segurança no tráfego de informações entre aplicações, mediante consentimento do usuário. O mesmo faz com que seja possível que uma plataforma consuma recursos limitados de uma aplicação terceira, sem que seja necessário obter informações de acesso do usuário, contando apenas com a autorização do mesmo através de dados de login da controladora dos recursos. Garantindo assim que a solicitante não tenha conhecimento destes dados de acesso, os quais pertencem apenas a detentora dos recursos que é o usuário.

Em resumo, o usuário concede a aplicação terceira o acesso restrito a determinados recursos que estão hospedados em outro controlador. Isso é feito no processo em que o usuário autoriza o acesso com um login na plataforma proprietária dos dados e concede a liberação ao terceiro, gerando assim um Authorization Code. Com esta autorização, o client conseguirá criar tokens de acesso a estes recursos previamente controlados pelo Resource Server.

O que diferencia ele das demais autenticações?

No modelo tradicional de autenticação client-server, por exemplo, as aplicações solicitam acesso a um recurso protegido no servidor. Entretanto, a liberação é feita através de autenticação do usuário, o que lhe direciona a disponibilizar seus dados de acesso à terceiros sem limitações pré-definidas pela dona de tais recursos, ou seja, não existe a camada de proteção como no OAuth, o que pode causar os seguintes problemas:

• Aplicativos de terceiros são necessários para armazenar o recurso de
  credenciais do proprietário para uso futuro, geralmente uma senha em
  texto claro, o que pode gerar problemas de segurança e de confiabilidade.
• Servidores são necessários para oferecer suporte à autenticação por senha, apesar de as fraquezas de segurança inerentes às senhas liberadas.
• Aplicativos de terceiros obtêm acesso excessivamente amplo aos recursos
  protegidos pelo proprietário, deixando os donos dos recursos sem capacidade de restringir a duração ou o acesso a um subconjunto limitado de informações.
• Os proprietários de recursos não podem revogar o acesso a terceiros individuais sem revogar o acesso a todos os terceiros e deve fazê-lo alterando a senha de acesso na dona dos recursos. Ou seja, para cancelar o acesso de um client, seria necessário cancelar o acesso de todos.
• O comprometimento de qualquer aplicativo de terceiros resulta no comprometimento para com a senha do usuário final e todos os dados protegidos por essa senha.

É válido lembrar que com este protocolo, nenhum dos problemas acima ocorreria. Afinal, o usuário efetua a concessão na própria hospedeira dos recursos e cria limitações por informação disponibilizada, podendo estar de acordo ou não com as liberações solicitadas.

Roles OAuth 2.0

Antes de continuarmos é importante entendermos quem é responsável por cada papel e identificarmos, na nomenclatura do protocolo, quais são as definições de cada um, pois muitas estarão presentes no artigo.

1. Client — Aplicação que interage com o Resource Owner (usuário) podendo ser um mobile, web app ou desktop. O client é o que solicitará acesso aos recursos e que por sua vez será a interface de comunicação com este usuário a qual aprovará ou não o consumo de seus dados por meio desse protocolo.
2. Resource Owner — É a pessoa (entidade) que concede o acesso aos seus dados. Literalmente, o Dono do Recurso. E também, a classificação utilizada pelo protocolo para definir o usuário final.
3. Authorization Server — Responsável por autenticar e emitir tokens de acesso (Access Token). Detém informações do Resource Owner. Autentica e interage com o usuário após identificar e solicitar autorização para acesso do Client a seus recursos.
4. Resource Server — É o controlador que possui e gerencia os dados do Resource Owner, a qual atua como o gerenciador dos recursos do usuário. Para conseguir acesso ao seu conteúdo é necessário um token emitido pelo Authorization Server. Com este token, o client conseguirá acessar os recursos do resource owner e assim replicá-los em sua aplicação.

Como isso funciona na prática?

Para entendermos melhor o conceito do protocolo na prática, vamos observar a representação gráfica abaixo, com o fluxo de consentimento e obtenção de recursos.

No fluxo de autenticação acima, é possível identificar os momentos e liberações efetuadas. Deixando clara a camada OAuth no intermédio do processo, onde ficam evidentes as trocas de autorização entre aplicação, usuário e controladora dos recursos.

Em linhas gerais o client (aplicação) solicita ao resource owner (usuário) a autorização de acesso aos recursos hospedados no resource server (gerenciador dos recursos), quando concedida esta permissão, o client consegue gerar tokens através do Authorization Server, que o possibilitará a ter acesso aos resources (recursos) do usuário.

Abaixo, detalharei o fluxo de autorização em cada etapa:

• Consentimento do Usuário (Authorization Request).

No fluxo abaixo, o cliente acessa a aplicação terceira Client a qual solicita autorização para consumir os recursos do usuário Resource Owner em uma outra plataforma Resource Server. Solicitando a aprovação do usuário mediante login na plataforma externa, devolvendo ao Client um (Authorization Grant). O que quer dizer que o cliente concedeu-lhe acesso aos seus recursos.

No fluxo acima, o usuário interage com a aplicação terceira a qual solicita acesso aos recursos, sendo limitados quais serão estes disponibilizados e reportados ao usuário, o qual consente na liberação dos dados e a controladora dos recursos disponibiliza acesso à aplicação terceira (Authorization grant).

É importante lembrar que para que o fluxo acima ocorra, o client deverá estar cadastrado como tal no resource server, cadastro o qual deverá ser previamente ajustado. Normalmente são feitos via API e são disponibilizadas chaves de identificação ou não, dependendo do tipo de client.

Normalmente as aplicações externas disponibilizam uma web view que pode ser solicitada através de uma rota e exibida para o usuário na aplicação terceira. Assim é possível que o usuário acesse a aplicação gerenciadora dos recursos e dos seus dados de acesso por esta interface.
Neste processo o client chama essa rota para que o usuário consinta na aplicação externa. Quando consentido, em conjunto ao Authorization Code o authorization server também efetua a chamada de uma redirect uri, para que o usuário possa voltar a aplicação de origem (client).

Com o consentimento do usuário Authorization grant em posse da aplicação terceira, a mesma solicitará a dona dos recursos os tokens de acesso aos dados deste usuário. Estes tokens darão acesso aos recursos pré-estabelecidos pela hospedeira dos mesmos.

• Solicitação de Tokens (Authorization Server).

Após conseguir o consentimento do cliente no fluxo acima, a dona dos recursos disponibiliza um Authorization Code para a aplicação Client. Com este é possível obter Tokens, os quais garantirão acesso aos recursos do usuário, estes por sua vez serão validados pelo Authorization Server. O qual em casos de autenticação bem sucedida, devolverá os tokens de acesso aos recursos do usuário.

Com os tokens em posse do client, a mesma terá a possibilidade de efetuar a solicitação de recursos ao controlador de tais dados Resource Server.

Em casos de retorno positivo da criação dos tokens, as aplicações enviam um acess_token e um refresh_token, sendo que cada um tem uma validade pré-estabelecida, onde ocorre de muitas vezes ao vencer este período ser necessário solicitar nova autorização ao usuário, o que reiniciaria este processo por motivos de segurança.

• Solicitação de Recursos (Resource Server).

Agora que a aplicação possui a autorização do usuário Authorization Grant e o token de acesso ao seus dados (Acess Token), a mesma solicitará ao controlador de tais recursos o acesso ao mesmos. Sendo confirmados pelo resource server a veracidade destes tokens, os recursos do usuário serão liberados para o client.

Com o fluxo acima, a aplicação client passa a receber os dados liberados pelo usuário resource owner no fluxo e poderá utilizá-los em sua plataforma.

Existem inúmeros recursos que podem ser liberados para consumo do client pelo resource server mediante autorização do usuário. Dependendo de cada controlador e permissões previamente expostas ao resource owner.
Pensando que o fluxo acima fora realizado em uma plataforma de fotos, o client agora passaria a ter acesso a estes recursos também, sendo possível criar, editar ou baixar fotos do resource server. Recursos estes os quais foram autorizados pelo dono deles (resource owner).

Como efetuar as integrações?

Para efetuar as integrações, primeiro precisamos entender como funciona cada etapa do processo e analisar casos reais de como fazê-los e replicá-los neste artigo. Além disso é importante ter em mente se você será o Client ou o Resource Server.

Entendendo o (Client)

Se você se identifica com a aplicação terceira conhecida no protocolo como client, precisa se atentar em algumas da dicas que serão detalhadas abaixo:

1. Obtenha o seu clientId e secrect da aplicação gerenciadora dos dados. Esse será o cadastro da sua aplicação no servidor de autenticação da controladora e lhe dará permissão para solicitar autorização dos usuários. É importante lembrar que dependendo do tipo do client estabelecido pela controladora, é possível que o mesmo não tenha secret criada.
   client public: Não contém secret, apenas clientId.
   client confidential: Contém a secret e o clientId.
2. Forneça ao controlador dos recursos, suas rotas de redirecionamento redirect URI. Estas são as rotas seguras, que farão com que após a autorização do usuário o mesmo possa retornar a sua aplicação.
   Vale a ressalva de que esta rota deverá estar protegida pelo protocolo HTTPS.
3. Após o consentimento do usuário, você precisará armazenar o Authorization Code, pois esta será a chave que em conjunto ao itens acima fará com que consiga o Acess Token de acesso aos recursos do determinado usuário.
4. Após conseguir o Acess Token, armazene-o em conjunto ao Refresh Token que a controladora informará.
   O Refresh_Token será utilizado para atualizar o Acess_Token quando o mesmo expirar, pois estes tokens são disponibilizados com limite de tempo para expiração por questões de segurança.
   Um ponto de atenção é que normalmente os controladores devolvem em seus JSON’s um campo chamado expires_in, que é o tempo para a expiração dos tokens.
5. Com o acess_token em posse, você poderá então solicitar acesso aos recursos do usuário e conseguirá acessá-los mediante aprovação do Resource Server.

Entendendo o (Authorization Server + Resource Server)

Caso a sua aplicação seja a controladora dos recursos do usuário e tenha a intenção de liberação dos dados via autenticação pelo protocolo OAuth 2.0, atente-se a alguns pontos importantes para a sua disponibilização.

1. É necessário que disponibilize uma forma de que os Clients consigam se cadastrar em sua plataforma, normalmente isso é feito via API, onde é disponibilizado uma rota específica a qual efetua o cadastro do Client em sua aplicação, os campos os quais você solicitará para este cadastro, são de controle seu. É importante apenas que você tenha uma forma de gerenciar, identificá-los e conceder liberações. A API é apenas um dos modos que você poderá escolher como método de cadastro dos seus clients.
2. O client precisará chamar uma rota para disponibilizar o frame da aplicação gerenciadora do acesso a sua aplicação, portal, site, etc. Para isso, crie uma webview ou mesmo uma rota para que seu client consiga disponibilizar ao resource owner em sua aplicação sem que seja necessário o acesso em mútuos locais.
   Neste deverá ser possível o usuário acessar a sua aplicação e dar consentimento a liberação dos recursos apontados.
3. Quando o usuário efetuar o processo acima, você precisará garantir ao client o sucesso ou não da liberação dos recursos do usuário, para isso você precisará retornar um Auhtorization Code para o client e em conjunto chamar uma redirect uri do client, que fará com que o usuário volte automaticamente para a plataforma do mesmo e seja possível seguir com o processo.
   Normalmente, o método mais utilizado na integração consiste na criação de um servidor de autenticação no meio deste fluxo, o qual é o do exemplo para o qual estou descrevendo neste. Para isso, você precisará de um authorization server, o qual concederá ao client um Authorization Code que foi resultante ao consentimento do usuário no fluxo anterior.
4. Agora será possível gerar tokens de acesso, para isso será necessário uma rota para geração deles, os quais validarão o authorization code do usuário e as informações do client. Com as informações compatíveis, deverão ser liberados os acess_token, refresh_token, expires_in, etc.
5. Com o acess_token em posse do client, o mesmo agora poderá chamar as suas rotas e consumir os recursos do usuário. Para isso você precisará criar rotas específicas para estes recursos hospedados no resource server. Será necessário validar o acess_token e validar se é correspondente àquele authorization code o qual foi gerado para o resource owner e client no fluxo.
6. Além dos recursos, pode ser que o client precise atualizar o acess_token que expirou, para isso você precisará disponibilizar uma rota a qual efetue o refresh_token, gerando novo acesso e reiniciando o tempo de expiração.
7. Tendo os tokens validados, o client poderá efetuar solicitações previamente ajustadas com o usuário. Sendo assim, será possível por exemplo disponibilizar uma rota de ativação de fluxo de arquivos. Onde além de enviar as informações para o usuário, possa enviá-las também ao client, que conseguiu consentimento do usuário para tais ações.

Aplicação

O protocolo pode ser implementado em diferentes segmentos, possibilitando inclusive a comunicação entre plataformas de atuações distintas em busca de uma mesma solução: O consentimento do usuário para acesso aos seus dados.

Um caso de exemplo pode ser constatado no mercado de Conciliação e Meios de Pagamento, onde o usuário possui acesso as duas ferramentas, mas precisa que os seus dados que estão hospedados em uma sejam utilizados pela outra.

Afim de melhor descrever, imagine o cenário onde um usuário que possua dados hospedados no meio de pagamento (x), precise que estes sejam enviados a plataforma de conciliação (y).
Sem o OAuth 2.0 haverá burocracia e uma série de condições impostas ao usuário, as quais tornarão o processo moroso e lento para ambas as ferramentas.
Com o OAuth 2.0, seria necessário apenas a implementação do protocolo e a comunicação via API, assim o usuário conseguiria consentir na utilização dos seus dados e as plataformas fariam isso de forma automática, contando apenas com a aprovação do dono daqueles recursos, que é o usuário.
Sendo assim, o usuário de fato se torna dono dos seus recursos e fica livre para utilizá-lo como e onde quiser.
Neste modelo, o meio de pagamento (x) validou o consentimento do seu usuário e passou a enviar os recursos do mesmo a plataforma de conciliação (y), que passará a visualizar e consumir os dados com base na liberação do usuário.

Referências

OAuth 2.0.