De uma forma bem resumida, delegar acesso nada mais é do que permitir que uma aplicação A acesse os recursos de um usuário em uma aplicação B, sob seu nome, mas sem requisitar que ele entre com suas credenciais em A (aplicação de terceiros). Desta forma, em nenhum momento a aplicação consumidora (A) fica sabendo das credenciais do usuário, o que é, sem sombra de dúvida, a maior falha de segurança que um sistema pode oferecer à integridade dos seus usuários.
Mais do que isso, sistemas de delegação de acesso se propõem a fornecer acesso personalizado para aplicações sobre seus recursos. Assim, é possível restringir o escopo de acesso de aplicações de terceiros sobre estes recursos, seja limitando as ações possíveis (ler, escrever), limitando áreas de acesso (somente uma pasta de fotos, ou somente os contatos de um determinado grupo), por um tempo determinado (quinze minutos, uma hora) e permitindo que posteriormente o escopo de acesso seja modificado ou removido sem prejuízos ao usuário ou sistema.
Por fim, um sistema de delegação de acesso bem implementado é seguro e confiável, uma vez que todos os protocolos atuais seguem rígidos padrões de segurança, como criptografia de chaves, tokens únicos com vida útil (nonces e timestamps) e cadastro prévio de aplicações consumidoras. Note que, ainda que um excelente sistema de delegação de acesso seja utilizado por provedores de recursos, nada é mais seguro do que um usuário bem informado e consciente.
Basicamente existem três grandes problemas relacionados ao fornecimento de acesso a terceiros sobre recursos existentes em sua aplicação, sendo eles os pilares da delegação de acesso. São eles: segurança dos usuários, segurança do sistema e escopo do acesso.
Segurança do usuário
Segurança do usuário trata basicamente de manter sigilo sobre as credenciais dos seus usuários, uma vez que elas são as chaves para se obter acesso completo aos recursos do mesmo. Aplicações que desejam fornecer seus recursos a terceiros, não podem, de maneira alguma, permitir que consumidores conheçam as credenciais dos seus usuários. Hoje existem centenas de aplicações que se propõem a realizar diversos serviços para o usuário, que requisitam a entrada das credenciais do mesmo. Uma vez que o usuário entra com suas credenciais nestes sites, ele está à mercê da índole do desenvolvedor do sistema.
Algumas aplicações web bem conhecidas, como Meebo e Power (antigo Power Scrap), são exemplos perfeitos de sistemas em que o usuário está nas mãos do desenvolvedor. Nestes sistemas, a página inicial solicita que os usuários entrem com suas credenciais do provedor de serviço que desejam acessar, como mostra a figura 1 abaixo, o que é uma prática totalmente desaconselhável por motivos óbvios, mas que não custa nada reforçar: você está dando suas credenciais de acesso para o desenvolvedor fazer o que bem quiser com elas. É o mesmo que você dar seu cartão de crédito e senha para que o garçom pague a conta do restaurante para você.
Segurança do Sistema
Segurança do sistema engloba as medidas que se deve tomar para evitar que uma aplicação de terceiros possa vir a prejudicar o sistema provedor de recursos. Entenda prejudicar como afetar a integridade dos seus dados, o funcionamento do sistema e também a sua relação de confiança com seus usuários. O principal motivo hoje para a existência de protocolos de delegação de acesso proprietários é o fato de que as empresas não tinham um meio eficaz de garantir a sua segurança e de seus usuários de uma forma padronizada e aberta, ao mesmo tempo em que fornecem acesso aos seus recursos a terceiros.
Segurança do sistema é muito mais do que armazenar as credenciais dos usuários em bancos relacionais e está além de “apenas” colocar o site sobre SSL. É importante que desenvolvedores de provedores de recursos tenham conhecimento do maior número possível, senão de todos, os aspectos de segurança que possam interferir com o bom funcionamento e integridade do sistema como um todo, incluindo seus usuários. Obviamente estes aspectos variam de serviço para serviço, mas para quem provê acesso aos seus recursos à terceiros, optar por um bom sistema de delegação de acesso já é um bom começo.
Escopo de Acesso
E por fim, o escopo do acesso delimita quais recursos poderão ser visualizados ou até mesmo alterados por quais aplicações e em qual faixa de tempo. O escopo do acesso consolida a segurança do usuário e do sistema, restringindo o acesso de terceiros somente às tarefas e recursos previamente estabelecidos, garantindo que ninguém, exceto o usuário final e o sistema provedor de recursos, tenha acesso completo à aplicação.
Mais do que apenas delimitar quais “pastas”, “contatos” e “fotos” aplicações de terceiros podem acessar, o escopo de acesso é responsável por definir o limite de tempo em que estes recursos estarão disponíveis e quais serviços possuem permissões sobre eles. Sem sombra de dúvida, esse controle “personalizado” sobre o acesso aos seus recursos, é uma das maiores motivações para se adotar um sistema de delegação de acesso aberto como o OAuth, devido à sua flexibilidade e adequação ao problema do desenvolvedor. E são esses problemas que serão tratados a seguir.
Problemas
Se for analisado o cenário atual no que diz respeito à delegação de acesso é fácil notar que existe um único e grande problema: a falta de um padrão aberto que seja adotado por grandes empresas. Os gigantes dos serviços online como AOL, Yahoo e Google, desenvolveram suas próprias maneiras de delegar acesso. Todas são ótimas soluções: são robustas, seguras e confiáveis. Porém, como todo protocolo proprietário, deixam de mãos atadas os desenvolvedores que desejam utilizá-los em suas aplicações, ou que não possuem exigências tão grandes como os milhões de acessos diários que estas empresas recebem.
Um desenvolvedor que deseje, por exemplo, criar um serviço de revelação de fotos de álbuns online a partir de suas fotos do Flickr e do Picasa, teria de desenvolver um cliente de delegação de acesso para o Flickr Auth (sistema de delegação de acesso do Flickr) e outro para o Google AuthSub (afinal, o Picasa é do Google). Quanto mais opções o desenvolvedor quiser agregar à sua aplicação, maiores serão os transtornos relacionados ao estudo e desenvolvimento de clientes para cada protocolo envolvido.
Esta falta de padrão foi o impulso maior para o desenvolvimento de um protocolo aberto e extensível, que não somente se propusesse a delegar acesso a um serviço específico, mas extensível e personalizável a qualquer sistema provedor de recursos (HUENIVERSE, 2009). Um protocolo que não ditasse regras de como realizar conexões seguras, mas fornecesse guidelines com as melhores práticas existentes, encontradas inclusive nos protocolos proprietários. Em 2007 o rascunho do protocolo OAuth 1.0 foi lançado para resolver este problema, largamente comentado neste mesmo blog em outros posts.
Referências
HUENIVERSE. Beginner’s Guide to OAuth. Disponível em: < http://hueniverse.com/oauth/>. Acesso em: 20 set. 2009.
HUENIVERSE. Explaining OAuth. Disponível em: < http://www.hueniverse.com/hueniverse/2007/09/explaining-oaut.html>. Acesso em 30 ago. 2009.
HUENIVERSE. Would you like Quechup with your Phish & Chips?. Disponível em: < http://www.hueniverse.com/hueniverse/2007/09/would-you-like-.html>. Acesso em 07 set. 2009.
POWER. Disponível em: <http://www.power.com>. Acesso em: 22 nov. 2009.
Autor
Luiz Fernando Duarte Junior é graduado em Ciência da Computação com pós-graduação na área de Computação Móvel. Professor do ensino superior, gerente de projetos, empreendedor e palestrante, é tradutor de um livro sobre criação de apps e autor de outro sobre o mesmo assunto, ambos disponíveis na seção Meus Livros.
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.