O OAuth 2.0 é definido como um framework de autorização que permite aplicações de terceiros obter acesso limitado a serviços HTTP, tanto em seu próprio nome como em nome de outros, comumente o usuário final. Acesso limitado diz respeito a o que uma aplicação de terceiro vai ter acesso em um determinado serviço.

A partir dessa definição é possível extrair os papéis estabelecidos pelo OAuth 2.0, mas antes disso vamos entender o problema que o framework se propõe a resolver.

O problema a ser resolvido

Nós primórdios da interação cliente-servidor, para um cliente obter acesso a recursos protegidos em um servidor e em nome de outra pessoa, era comum que essa pessoa, dona do recurso protegido, compartilhasse suas credenciais (comumente usuário e senha) com a aplicação cliente.

Imagine o seguinte: você acessa uma aplicação de controle financeiro (cliente) que consegue consolidar as suas transações financeiras (débitos e créditos) de vários bancos (servidores) em um único lugar, mas para isso você precisa fornecer para essa aplicação de controle financeiro o usuário e senha de cada banco que você deseja que as informações sejam consolidadas.

Assustador, não? Pois era assim que o acesso era concedido antigamente.

Essa abordagem de compartilhar suas credenciais com aplicações de terceiros para que essas possam acessar recursos (serviços) em seu nome, possui diversos problemas:

• A aplicação cliente precisava armazenar seu usuário e senha para poder realizar acessos / consultas futuras. Tipicamente essas informações eram armazenadas em texto plano;

• Os serviços eram obrigados a suportar autenticação baseado apenas em usuário e senha (MFA inviabilizaria os acessos da aplicação cliente);

• A aplicação cliente ganhava acesso a todos os recursos e não apenas a um conjunto de recursos definidos por você.

• Para revogar o acesso da aplicação cliente você precisaria alterar sua senha.

O protocolo OAuth 2.0 surgiu visando resolver esses problemas.

Os papéis estabelecidos pelo OAuth 2.0

A partir da definição apresentada e do problema que o framework busca resolver é possível extrair 3 dos 4 papéis definidos pela especificação:

• Resource Owner: Trata-se do dono dos recursos a serem acessados. No cenário da aplicação de controle financeiro seria você. Os dados sendo compartilhados são seus e você quem tem o poder de autorizar ou não tal compartilhamento.

• Resource Server: Trata-se do serviço que possui os recursos que serão acessados e que devem ser fornecidos apenas mediante sua autorização. No cenário da aplicação de controle financeiro seriam os bancos.

• Client: Trata-se da aplicação que deseja obter recursos em seu próprio nome ou de outro. No cenário da aplicação de controle financeiro seria a própria aplicação de controle financeiro.

O quarto papel definido pela especificação é o do Authorization Server, sendo esse responsável por emitir, a partir da interação com o Client e/ou Resource Owner, tokens de acesso que serão entregues ao Client para que essa possa consumir serviços disponibilizados pelo Resource Server.

Observe que com a definição desses papéis e responsabilidades o usuário irá realizar a autenticação diretamente com o Authorization Server, não precisando mais fornecer suas credenciais para a aplicação cliente. Finalizado o processo de autenticação o Authorization Server emite para o Client um access token que por sua vez o utiliza em cada requisição realizada ao Resource Server. Há aqui, implicitamente, uma relação de confiança estabelecida entre Resource Server e Authorization Server. Cabe ao Resource Server verificar junto ao Authorization Server se o access token recebido é válido para então atender ou não a requisição realizada pelo Client.

A interação que ocorre entre client, resource owner e authorization server é comumente chamada fluxos de autorização (authorization flow / authorization grant).

Authorization flows

A RFC 6749, onde o OAuth 2.0 é definido, estabelece quatro fluxos distintos. Para cada um dos fluxos a especificação estabelece as ações e passos necessários até a obtenção do access token. Os fluxos definidos são:

• Authorization Code Flow

• Implicit Flow

• Resource Owner Password Credentials

• Client Credentials

Os próximos artigos dessa série irão abordar cada um desses fluxos.

Te vejo lá :)

#disclaimer

Dicas, sugestões, correções e críticas construtivas são bem-vindas.