OAuth - Compartilhando meus estudos

Em agosto de 2009 eu tive a tão aguardada tarefa de decidir o que eu faria no meu Trabalho de Conclusão de Curso (TCC) em Ciência da Computação. Como estava sem criatividade na época, deixei-me levar pelas dicas dos professores sobre temas que poderiam ser de interesse da banca avaliadora e até mesmo para o bem comum. Acabei optando por estudar o protocolo aberto OAuth, conforme brilhante sugestão do meu orientador, o prof. Tales Bitelo Viegas.

OAuth era um assunto completamente desconhecido para mim, e ao procurar informações na Internet, notei que simplesmente não havia nada em português. Obviamente um formando não deve ter problemas com inglês depois de mais de 4 anos estudando tecnologias documentadas em inglês. Dessa forma, isso se tornou um motivador para o trabalho, pois eu desenvolveria algo que ainda não havia sido feito em idioma tupiniquim e além do mais, com uma linguagem que ainda não tinha sido usada para implementar servidores de delegação de acesso, o C#.

Hoje, alguns anos mais tarde, já existem outras bibliotecas OAuth escritas em .NET, mas como ainda acho que os meus estudos podem ser de utilidade para mais alguém (infelizmente não segui meu Mestrado nesta área) devo compartilhá-lo numa série de posts com a tag OAuth, a começar por esse.

Você vai ver neste post:

• Explicando OAuth
• Um pouco de história
• Para que serve?
• OAuth e OpenID
• Quem é que vai usá-lo?
• Isto não é igual aquele outro protocolo?
• Era uma vez

Vamos lá!

Explicando OAUTH

Este post nada mais é do que uma tradução livre do original em inglês “Explaining OAuth”, disponível no antigo site Hueniverse, que era mantido por um dos idealizadores do protocolo, e é sem sombra de dúvida a melhor fonte de informação sobre o protocolo na Internet. Melhor até do que o site oficial, OAuth.net.

OAuth (pronuncia-se “Oh Auth”) é mencionado em muitos posts de blogs, normalmente no contexto de OpenID e Open Social Networks. Enquanto OAuth pode interpretar um importante papel ao ajudar na abertura de comunidades fechadas, ele não é específico de redes sociais. A explicação (mais) curta de OAuth é “um protocolo de delegação de acesso à APIs”. Agora vamos a mais comprida.

Um pouco de história

OAuth começou em novembro de 2006, enquanto Blaine Cook estava trabalhando na implementação do Twitter OpenID. Ele entrou em contato com Chris Messina buscando por uma forma de usar OpenID junto com a Twitter API para delegar autenticação. Eles encontraram com David Recordon, Larry Halff, e outros no encontro OpenID CitizenSpace para discutir sobre as soluções existentes. Larry estava buscando como integrar OpenID para os Widgets do Ma.gnolia Dashboard. Depois de reverem as funcionalidades existentes no OpenID, bem como de outras práticas industriais, eles chegaram a conclusão de que não havia um padrão aberto para delegação de acesso a API. A conversa continuou online e e offline por alguns meses.

Em Abril de 2007, um Google Group foi criado com um pequeno grupo de implementadores para escrever uma proposta para um protocolo aberto. Descobriu-se que este problema não era único do OpenID e quando DeWitt Clinton do Google entrou na onda do projeto, ele expressou seu interesse em auxiliar o esforço, somente como um stakeholder. Em julho de 2007 o time rascunhou uma especificação inicial e o grupo estava aberto para qualquer um que quisesse contribuir. Depois de muitas discussões online e cara a cara, o draft OAuth 1.0 será lançado na próxima semana.

Para que serve?

Muitos carros luxuoso de hoje vem com uma valet key (chave valete). Ela é uma chave especial que você dá ao atendente do estacionamento e diferente de sua chave normal, ela não permitirá que o carro seja dirigido por mais de uma milha ou duas. Algumas valet keys não abrirão o porta-malas, enquanto outras bloquearão o acesso à sua agenda do telefone de bordo. Indiferente a quais restrições a valet key impõe, a idéia é muito clara. Você dá a alguém acesso limitado com uma chave especial, enquanto usa outra chave para liberar todo o resto.

Todo dia um novo website oferece serviços que agrega junto funcionalidades de outros sites. Um laboratório de impressão de fotos revela o seu Flickr, uma rede social usa sua agenda do Google para procurar por amigos, e APIs para montar sua própria versão de aplicação desktop de um site popular. Estes são todos grandes serviços – o que não é tão grande quanto algumas das implementações disponíveis hoje é o seu pedido para o seu nome de usuário e senha em outro site. Usando o Twitter como exemplo, o site possui uma simples e poderosa API criou uma comunidade rica de aplicações construídas sobre sua plataforma. Mas para que esses pedidos para atualizar seu status no Twitter, eles devem pedir a sua senha. Quando o fazem, não somente você expõe sua senha para alguém senão (sim, aquela mesma senha que você também usa para o internet banking), você também dá total acesso para fazer o que eles quiserem. Eles podem fazer qualquer coisa que quiserem – até mesmo trocar sua senha e lhe negarem o acesso.

Isto é o que o OAuth faz, permite ao Usuário conceder acesso aos seus recursos privados em um site (que é chamado de Provedor de Serviço – Service Provider), para outro site (chamado Consumidor – Consumer, não confundir com você, Usuário). Enquanto OpenID é tudo sobre usar um única identidade para assinar em muitos sites, OAuth é sobre dar acesso às suas coisas sem compartilhar todas elas (ou as partes secretas).

OAuth e OpenID

OAuth não é uma extensão de OpenID e em um nível de especificação, compartilha somente poucas coisas com OpenID – alguns autores comuns e em ambos o fato que são especificações abertas na área de autenticação e controle de acesso. “Porque OAuth não é uma extensão do OpenID?” é provavelmente a pergunta mais comum no grupo, e também a minha primeira quando me juntei ao esforço OAuth. A resposta é simples, OAuth se propõe a ser uma forma padronizada para desenvolvedores oferecerem seus serviços via uma API sem forçar seus usuários a exporem suas senhas (e outras credenciais). Se OAuth dependesse de OpenID, somente serviços OpenID poderiam estar apto a utilizá-lo, e mesmo que OpenID seja grande, há muitos aplicações em que ele não é adequado ou desejado. O que não significa que não seja possível usar os dois em conjunto. OAuth fala sobre garantir acesso aos usuários enquanto OpenID fala sobre ter certeza de que os usuários são quem realmente afirmam ser.

Quem é que vai usá-lo?

Se você é um desenvolvedor web – você, nós esperamos. Ao mesmo tempo em que estamos escrevendo isto, nós esperamos implementações iniciais de (em ordem alfabética) Digg, Jaiku, Flickr, Ma.gnolia, Plaxo, Pownce, Twitter e esperançosamente Google, Yahoo, e outros em breve os seguirão. Dado meu foco pessoal em micro-blogging, é particularmente gratificante contribuir para um serviço que irá ser usado por três líderes no espaço, Jaiku, Pownce e Twitter. Nouncer irá, obviamente, suportar o mesmo quando for lançado.

Isto não é igual aquele outro protocolo?

OAuth é uma padronização e sabedoria combinada de muitos protocolos industriais bem estabelecidos. Ele é similar a outros protocolos correntemente em uso (Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr API, Amazon Web Services API, etc). Cada protocolo provê diferentes métodos para trocar credenciais de usuário para acessar um token ou ticket. OAuth foi criado pelo estudo cuidadoso de cada um destes protocolos e extrai as melhores práticas e coisas em comum que permitirão novas implementações bem como uma suave transição para serviços existentes suportarem OAuth.

Uma área onde OAuth está mais envolvido do que alguns dos outros protocolos e serviços é o manejo direto de serviços não-websites. OAuth foi construído para suportar aplicações desktop, dispositivos móveis, set-top boxes, e é claro, websites. Muitos dos protocolos hoje usam hardcode secreto compartilhado dentro de seu software para comunicar, algo que constitui um problema quando o serviço que tenta acessar seus dados pessoais é open source ou hackeável.

Era uma vez

Esta é – de forma breve – como a história aconteceu. Eu tentarei somar conhecimento usando um website como exemplo. Você é o Usuário que loga em um site Consumidor (Consumer) pedindo-lhe para fazer alguma coisa para você, utilizando seus recursos protegidos em um outro local (Service Provider). O Consumidor envia você para o Provedor de Serviço com a informação identificando sobre você e o que você está tentando acessar. Quando você chega ao Provedor de Serviço você assina e é questionado se você quer dar acesso ao Consumidor. Somente se você aceitar o Provedor de Serviço enviará você de volta para o Consumidor com um token-único especial de usuário. Neste ponto você está pronto como um Usuário. O Consumidor irá agora tomar o Token Usuário-Único e contatar o Provedor de Serviço para trocá-lo por um Token Multi-Usuário, o “ticket” que pode ser usado agora para acessar seus Recursos Protegidos no seu interesse. Este é claramente um fluxo simplificado, não detalha a segurança e verificação que o protocolo inclui.

Tokens podem viver para sempre, ter uma vida limitada, ou serem restritos a algumas atividades. Por exemplo, um Token pode permitir ao Consumidor trocar seus dados, enquanto outro Token é somente bom para acesso somente-leitura. Um serviço de impressão acessando seu Flickr pode realmente ter acesso somente leitura, enquanto um novo serviço de correção de olho-vermelhos irá necessitar de permissão de escrita para corrigir as fotos.