O OAuth é um padrão aberto para autorização, responsável por fornecer um método para acessar os recursos do servidor em nome de seu proprietário, além de fornecer também um processo para que os usuários possam autorizar o acesso de terceiros aos seus recursos, sem compartilhar suas credenciais.
O OAuth permite a aplicações acessar dados de um usuário de forma segura, sem que para isso o usuário necessite disponibilizar suas senhas.
História
O OAuth teve seu início por volta de novembro de 2006, quando Blaine Cook foi trabalhar na implementação Twitter OpenID e ao buscar uma maneira de usar o OpenID em conjunto com a API do Twitter se juntou a outros que possuíam necessidades similares, como Chris Messina, David Recordon e Larry Halff, analisaram as funcionalidades do OpenID e soluções práticas de outras empresas, e chegaram a conclusão de que não havia nenhum padrão aberto para a delegação de acesso à API. Em julho de 2007, agora com o apoio do Google, foi elaborada uma especificação inicial e o projeto foi aberto a qualquer pessoa interessada em contribuir. Em 3 de Outubro de 2007, a versão final do Núcleo OAuth 1.0 foi lançada.
A primeira versão do OAuth foi projetada para lidar com autorização de aplicações web cliente-servidor, não definindo como lidar com autorização em aplicações móveis, desktop, javascript ou extensões do navegador por exemplo. Assim essas aplicações ao implementar o OAuth 1.0, normalmente possuíam métodos inconsistentes e muitas vezes de qualidade inferior, visto que eram obrigados a adaptar o protocolo a sua necessidade.
Com o lançamento da versão 2.0 do protocolo, essa limitação foi eliminada, visto que já foi projetada para trabalhar com todos esses tipos de aplicações de forma nativa.
Porque usar uma OAuth ao invés de senhas?
Para Boyd(2012) existem várias razões para se utilizar OAuth, sendo as principais:
- Confiança: O usuário pode não confiar em fornecer a senha a sua aplicação.
- Acesso e risco além do necessário: Ao fornecer sua senha a uma aplicação, o usuário disponibiliza não somente os dados necessários para ela, mais sim todos os dados que estão vinculados a aquela conta. Assim quando o usuário confia sua senha, cabe à mesma armazená-las de forma segura, criando mecanismos com o objetivo de evitar o vazamento dessa informação, o que pode gerar um custo desnecessário para a empresa.
- Alteração de Senha: Ao alterar a senha de uma conta, todas as aplicações vinculadas a ela irão parar de funcionar, fazendo que o usuário tenha que acessar aplicação a aplicação para inserir a nova senha.
- Revogação: A única maneira de revogar o acesso à aplicação será o usuário alterar suas senhas, o que também revoga o acesso a todos os outros aplicativos que o mesmo tenha concedido essa informação.
Papéis no OAuth
Existem vários componentes chaves que compõe os fluxos do protocolo OAuth. São eles:
- Servidor de recursos : O servidor que hospeda os recursos de propriedade do usuário que estão protegidos por OAuth. Este é normalmente um provedor de API que mantém e protege os dados, como fotos, vídeos, calendários e contatos.
- Proprietário dos recursos: Normalmente, o usuário de um aplicativo, o proprietário do recurso tem a capacidade de conceder acesso aos seus próprios dados hospedado no servidor de recursos.
- Cliente: É aquele que envia uma requisição à API, solicitando um recurso protegido em nome do proprietário.
- Servidor de autorização: O servidor responsável por receber a autorização de proprietário do recurso e conceder tokens de acesso para o cliente poder acessar, em nome do proprietário, os recursos protegidos hospedados em um servidor de recursos.
Fornecedores de API menores podem usar o mesmo aplicativo e URL, tanto para o servidor de autorização, quanto para o servidor de recursos.
Perfis de Clientes no OAuth 2.0
Existem três perfis de clientes implementados no OAuth 2.0, são eles: Aplicação executada pelo servidor (server-side), Aplicação executada pelo navegador de internet do cliente (client-side) e Aplicações nativas
Aplicação executada pelo servidor (server-side)
Para esse perfil a aplicação web é acessada por um usuário, proprietário do recurso, e ao ser consultada faz as chamadas da API apropriadas usando uma linguagem de programação do lado do servidor, não disponibilizando ao usuário o acesso aos tokens OAuth emitidos pelo servidor de autorização .
Na ilustração abaixo é demonstrado o fluxo de uma aplicação que busca autorização pelo lado do servidor.
Aplicação executada pelo servidor (server-side)
Aplicação executada pelo navegador do cliente (client-side)
Nesse perfil o acesso a API é efetuada diretamente no cliente, por intermédio de seu navegador, onde o mesmo tem acesso ao código do aplicativo e suas solicitações. Dessa forma o aplicativo pode ser distribuído em linguagem javascript, ou em uma extensão do navegador ou ainda usando uma tecnologia plug-in como o Flash.
Esse perfil, por rodar em um ambiente com pouco ou nenhum controle, possui fragilidades as quais fazem com que, por medida de segurança, alguns provedores não permitam o armazenamento de credenciais para clientes que utilizam esse perfil.
Aplicação executada pelo cliente (client-side)
Aplicações nativas
Aplicações com esse perfil são desenvolvidas para rodar como um aplicativo nativo em diversos dispositivos como computadores, smartphones ou tablets. Podendo assim aproveitar de todos os recursos do sistema operacional ao qual o dispositivo disponibiliza. Essas aplicações possuem características muito similares às executadas pelos navegadores de internet, como por exemplo, o fato de não ser um ambiente confiável para o armazenamento de credenciais. Porém como destaca Boyd(2012), uma vez que o aplicativo é instalado, pode não ter acesso a todos os recursos, como teria em um navegador de internet.
Fluxo de Autorização
Cada um dos perfis citados anteriormente precisa fazer uso de um protocolo adequado para a obtenção de autorização do proprietário do recurso de acesso a seus dados.
Em seu núcleo, o protocolo OAuth 2.0 define quatro principais mecanismos para a obtenção dessa autorização, além de também definir um de extensão para permitir tipos de autorização adicionais .
Concessão de código de autorização
Esse tipo de concessão é mais adequado para aplicações web que utilizam o perfil server-side. Depois que o proprietário do recurso autorizou o acesso a seus dados, eles são redirecionados de volta para a aplicação web com um código de autorização como um parâmetro de consulta na URL, sendo que este código deve ser trocado por um token de acesso pelo aplicativo cliente. Esta troca é feita de servidor para servidor e requer o client_id e client_secret, impedindo até mesmo o proprietário do recurso de obter o token de acesso.
Este tipo de concessão também permite o acesso de longa duração para uma API usando fichas de atualização.
Uma representação desse fluxo é demonstrada na ilustração abaixo, onde podemos visualizar a solicitação do recurso pelo cliente para o proprietário do recurso, que responde com uma concessão de autorização gerada pelo servidor de autorização, logo após a concessão de autorização é enviada ao servidor de autorização, que responde com um token de acesso que é usado para acessar o servidor de recursos e obter os dados aos quais obteve autorização prévia.
Fluxo de Código de Autorização
Concessão implícita
As concessões implícitas estão disponíveis como um método simplificado de geração do token de acesso para clientes públicos baseados em navegadores, pois ao invés de gerar uma concessão intermediária, como acontece no fluxo de Código de autorização, o token de acesso é emitido diretamente ao cliente depois de autenticar o proprietário do recurso.
As etapas ilustradas na imagem abaixo demonstram o fluxo de uma concessão implícita, onde :
- 1ª Etapa: O aplicativo solicita ao usuário a permissão de acesso a API do Facebook.
- 2ª Etapa: O usuário se conecta ao servidor de recursos por meio de uma URL que inclui informações sobre o aplicativo que está tentando acessar a API, como por exemplo, o client_id, e fornece um nome de usuário e senha para fazer login no facebook.
- 3ª Etapa: Com login efetuado com sucesso, o facebook concede ao aplicativo um token de acesso.
- 4ª Etapa: O aplicativo pode obter acesso aos recursos do usuário ao se utilizar do token recebido na etapa anterior.
Fluxo de concessão implícita
Fonte: KULP (2013)
Concessão com usuário e senha
Este tipo de concessão consiste em ao obter um nome de usuário do proprietário de um recurso e uma senha para que esses dados possam ser trocados por um token de acesso OAuth. Este tipo de concessão deve ser usado somente para clientes altamente confiáveis, tais como aplicações móveis escritas pelo provedor da API, visto que a senha do usuário é exposta ao cliente, que não necessita de armazená-la no dispositivo.
Após a autenticação inicial, apenas o token OAuth precisa de ser armazenado. Como a senha não é armazenada, o usuário pode revogar o acesso ao aplicativo sem alterar a senha, e o token é limitado a um conjunto de dados previamente autorizado pelo proprietário dos recursos, de modo que este tipo de concessão ainda proporciona maior segurança sobre a autenticação de usuário / senha tradicional.
Concessão de credenciais para o cliente
A concessão de credenciais de um cliente permite que um aplicativo possa obter um token de acesso a recurso de propriedade do cliente quando a autorização foi previamente definida com o servidor de autorização. Sendo esse tipo de concessão adequada para aplicações que precisam acessar APIs, tais como serviços de armazenamento ou banco de dados em nome da aplicação ou do fornecedor da aplicação e não em nome de um usuário específico.
Concessão de credenciais para um dispositivo
O concessão de credenciais para um dispositivo foi criada para permitir que o protocolo OAuth possa ser usado em dispositivos mais limitados, sem os recursos necessários para obter uma autorização por si só. Essa consiste em iniciar o fluxo no dispositivo e então utilizar dispositivo auxiliar, como um computador, por exemplo, para acessar um site e aprovar o acesso, digitando um código de autorização exibida no dispositivo.
Bibliografia
BOYD, R. Getting Started with OAuth 2.0. Sebastopol: O’Reilly Media, 2012.
KULP, T. Access Online Services with the Windows Runtime and OAuth. MSDN Magazine, 2014. Disponivel em:
<http://msdn.microsoft.com/pt-br/magazine/jj883954(en-us).aspx>. Acesso em: Março 2014.