Segurança: Protocolo OAuth 2.0

O protocolo OAuth 2.0 possibilita que um usuário autorize uma aplicação a acessar dados em seu nome sem precisar fornecer seu login e sua senha para essa aplicação.

Papéis

O protocolo OAuth 2.0 define os seguintes papéis:

• dono do recurso (resource owner): o usuário, tipicamente uma pessoa, que possui dados e que decide se autoriza ou não uma aplicação a acessar tais dados em seu nome.

• aplicação cliente (client application): a aplicação que deseja acessar dados em nome da pessoa. Esta aplicação pode ser:

  • uma aplicação web onde a autorização acontece no lado servidor.
  • uma aplicação web onde a autorização acontece no lado cliente, tipicamente por meio de um programa JavaScript executado pelo navegador (browser).
  • uma aplicação nativa (para desktop, celular, tablet, etc).

• servidor dos recursos (resource server): o servidor que armazena os dados da pessoa.

• servidor de autorização (authorization server): o servidor que autoriza a aplicação cliente acessar os dados do dono do recurso (pessoa) que estão armazenados no servidor de recursos. Muitas empresas, como Google, Facebook, Github, Amazon, fornecem o serviço de autorização OAuth 2.0. O seguinte link contém uma lista extensa de provedores deste serviço.

Atenção: No contexto da disciplina INE5646, o interesse está em utilizar o protocolo OAuth 2.0 em aplicações web com autorização acontecendo no lado do servidor.

Pré-condições para Utilização

Para que o protocolo OAuth 2.0 possa ser utilizado, a aplicação cliente precisa ser previamente cadastrada no servidor de autorização.

O objetivo do cadastro é garantir que apenas aplicações cliente autorizadas pelo usuário tenham acesso aos seus dados. Para isso são definidas duas informações importantes: um código de identificação da aplicação, chamado de client id, e uma senha para a aplicação, chamada de client secret.

Utilização

Token de acesso

A aplicação cliente acessa dados que não são públicos, em nome do usuário, usando uma senha especial chamada token de acesso (access token).

O token de acesso equivale, conceitualmente, ao par login-senha do usuário. O token, no entanto, possui as seguintes características:

• Prazo de validade curto (da ordem de minutos ou poucas horas).
• Pode ser invalidado pelo usuário a qualquer momento.
• Pode ter sua validade renovada por parte da aplicação cliente.

O servidor que recebe uma requisição solicitando dados não públicos tem condições de verificar se o token de acesso é autêntico e válido. Somente nessas condições ele retorna os dados pedidos.

Fluxo para obter um token de acesso

O procedimento para que uma aplicação cliente obtenha o token de acesso é o seguinte:

1. A aplicação cliente mostra no navegador do usuário uma página HTML que contém um link que aponta para o servidor de autorização. Este link contém, entre outras informações, o client id.

2. O usuário clica no link e passa a interagir com o servidor de autorização.

3. O servidor de autorização solicita que o usuário se identifique (forneça seu login e sua senha).

4. O servidor de autorização mostra uma página HTML que descreve a aplicação cliente e solicita que o usuário decida se ele autoriza ou não a aplicação cliente a acessar os seus dados não públicos.

5. Com a autorização concedida, o servidor de autorização gera um código de autorização (authorization code) que é entregue (via resposta HTTP) ao navegador do usuário.

6. O código de autorização é enviado (via requisição HTTP) ao lado servidor da aplicação cliente. Esta por sua vez envia uma requisição ao servidor de autorização com o objetivo de obter o token de acesso. Nesta requisição são enviadas, entre outras informações, o client id, o client secret e o código de autorização. O servidor de autorização pode então verificar se as informações são válidas e, gerar o token de acesso, e enviá-lo (via resposta HTTP) ao lado servidor da aplicação cliente.

7. A aplicação cliente deve guardar o token de acesso.

Fluxo para obter dados não públicos

Sempre que a aplicação cliente precisar de dados não públicos que estão armazenados no servidor de dados ela deve incluir na requisição HTTP o token de acesso. Com isso, o servidor de dados é capaz de saber

• se o token é válido
• qual aplicação cliente está querendo os dados
• qual o usuário autorizou a aplicação cliente

Desta forma é possível calcular estatísticas de utilização, definir políticas de cobrança e de limitações (número de acessos) sobre os dados.