OAuth (nem) sempre é a solução!

Este post é uma tradução livre do original “OAuth isn’t (Always) the solution” disponível no antigo site do Hueniverse. Ele compreende mais um de meus posts com o protocolo de delegação de acesso que foi tema de meu TCC. Conforme for encontrando os artigos e posts que escrevi ou traduzi, vou postando aqui pro pessoal conhecer o protocolo que é usado por gigantes da Internet como Google e Yahoo. Neste post, é abordada a questão de como o pessoal que curte o OAuth acaba muitas vezes usando o protocolo até mesmo em situações em que não deveriam. Saber quando usar ou não usar tecnologias específicas em situações específicas é o que costumo dizer que diferencia os bons desenvolvedores dos xiitas da linguagem X ou do protocolo Y. Enjoy it!


Não entenda errado, OAuth é grande, ou ao menos eu espero estar considerando o número de horas que eu pus esta semana deixando as especificações prontas. Mas eu tenho ouvido um monte de conversas sobre no que OAuth é bom e algumas fazem algum sentido para mim. Eu não quero apontar exemplos específicos como algumas pessoas que eu admiro fizeram, mas eles estão aqui. No Data Sharing Summit, OAuth foi jogado dentro de um conjunto de soluções para os problemas que ele nada podia fazer.

OAuth é perfeito para qualquer caso onde você não quer dar seu nome de usuário e senha, mas ao invés disso quer dar algo que você pode revogar a qualquer momento, dando acesso limitado a outro site sobre suas coisas. Eu tenho estado ocupado nas últimas noites escrevendo um novo exemplo completo para a especificação do OAuth. Ele começa mais ou menos assim:

“Neste exemplo, o Provedor de Serviço fotos.exemplo.com é um site de compartilhamento de fotos, e o Consumidor impressao.exemplo.com é um site de impressão de fotos. Jane, a Usuária, gostaria que impressao.exemplo.com imprimisse sua foto privada ‘férias.jpg’ armazenada em fotos.exemplo.com.

Quando Jane autentica-se em fotos.exemplo.com usando seu nome de usuário e senha, ela pode acessar a foto através da URL ‘http://fotos.exemplo.com/arquivo=férias.jpg’. Outros Usuários não podem acessar aquela foto, e Jane não quer compartilhar seu nome de usuário e senha com impressao.exemplo.com.”

Para mim, este é o melhor exemplo. Onde estão alguns lugares que OAuth não está? Iniciamos com o Provedor de Serviço. Isto deve soar óbvio mas não é (para algumas pessoas). Outro teste é se o OAuth torna a vida mais difícil. Se você atualmente somente entra seu nome de usuário e senha em alguma aplicação, mas terá que atravessar vários passos, telas e formulários, isto provavelmente significa que você não deveria ter usado OAuth.

OAuth substitui um diálogo para nome de usuário e senha (tipicamente um formulário de login – OAuth não menciona nomes de usuário e senhas especificamente) com dois diálogos: um para o nome de usuário e senha, e outro para lhe perguntar se você quer dar algum acesso ao site às suas coisas privadas. Isto é tudo. Se você leu OAuth e pensou que ele é perfeito para o que você está fazendo, pergunte a si mesmo se você está apto a manter este fluxo simples – se você não puder, é porque está usando a ferramenta errada.

OAuth e Phishing

Este post é uma tradução livre, feita por mim em 2009, do original “Would you like Quechup with your Phish & Chips?” (algo como “gostaria de catchup com seu peixe e fritas?”, trocadilho com a técnica de Phishing usada para enganar tontos na Internet e com o site Quechup que pegava os emails dos seus contatos para fazer spam). Artigo original disponível no antigo site do Hueniverse. Para quem não leu o meu primeiro post sobre OAuth, o protocolo aberto foi tema de meu TCC, defendido em 2010 em minha monografia de bacharelado.

A idéia de disponibilizar este post é para corrigir alguns erros comuns e preconceitos infundados que o pessoal tem com relação ao OAuth. Os gigantes Google, Facebook e Twitter usam OAuth. Por que VOCÊ não usaria?


Comentários públicos sobre OAuth são uma grande oportunidade para explicar a idéia e objetivos por trás do protocolo. Rob Sayre perguntou sobre usar o protocolo de redirecionamento para obter a permissão de acesso:

“Talvez eu esteja esquecendo algo, mas os usuários não são treinados para não colocarem suas credenciais em sites que foram redirecionados?”

Primeiramente, você está certo.

Redirecionamento leva o risco de usuários treinados seguirem um padrão de chegar a uma tela de login sem explicitamente entrarem a URL na barra de endereços do navegador. A idéia básica por trás do phishing é levar o usuário a uma página que ele pensa ser uma coisa mas na verdade é outra. Como um link em um e-mail feito para parecer do seu banco, mas que na verdade é uma página falsa pedindo seu nome de usuário e senha. Quando você digita suas credenciais, ela normalmente redireciona você de volta à página real do banco para que entre novamente (fazendo você achar que errou na hora de digitar algo).

O objetivo primário do OAuth é prevenir que você necessite compartilhar sua senha com aplicações legítimas que você realmente deseja usar. Muitos sites hoje em dia não providenciam uma API porque eles não querem as senhas dos seus usuários compartilhadas com ninguém. Mas como o Twitter prova, provendo uma API que pode ser o que o coloca à frente dos outros, e provendo uma API é tornar-se mais e mais essencial para rodar um negócio de internet. Com isto em mente, ter uma maneira consistente de delegar acesso é crítico.

A melhor solução para ataques de phishing é nunca entrar com sua senha em páginas da internet que você não entrou digitando o endereço no navegador (ou que não foi a partir dos seus favoritos). OAuth pode não ajudar usuários cuidadosos, e phishing é muito sobre não prestar atenção no que se está fazendo. Há uma discussão interessante sobre phishing no grupo de OAuth, embora isto seja além do escopo do protocolo. Guy Huntington faz alguns apontamentos muito bons sobre o assunto.

Para que o OAuth funcione, o Consumidor (site ou aplicação) tem de “pedir que o usuário conceda acesso” para poder pegar os Recursos Protegidos do Usuário. OAuth não diz como o Provedor de Serviço deve fazer isso. Alguns vendedores do OpenID não permitem que você assine a partir de um redirecionamento, ao invés disso eles pedem que você abra um novo navegador, vá até a tela de login e autentique-se manualmente. Eles somente permitem que você conceda acesso via redirecionamento uma vez que você já esteja logado. Provedores de Serviço OAuth podem implementar a mesma lógica que os ajudará a quebrar maus hábitos. Eles também podem usar OpenID para reduzir a quantidade de nomes de usuário e senhas que o usuário precisa cuidar.

Um ponto importante de ter em mente é que um dos objetivos do projeto OAuth é se manter o mais simples possível e fácil de implementar. Se você torná-lo muito difícil, aquelas aplicações de terceiros usarão o método tradicional de pedir o usuário e senha e postar os seus dados como já se faz hoje em dia. Google é um exemplo de companhia que conscientemente faz seu protocolo AuthSub perder apelo para os desenvolvedores adotarem-no (e pararem de fazer “screen scraping”).

Google AuthSub é perfeitamente seguro quando utilizado sobre HTTPS mas não muito quando utilizado sobre HTTP. A solução do Google é mostrar um aviso grande e vermelho quando você deseja dar acesso à outra aplicação em um canal não seguro. Todo mundo tem um compromisso em algum lugar. OAuth deixa para o Provedor de Serviço decidir o quão seguros seus recursos serão, enquanto estabelece um framework que os desenvolvedores podem usar através dos sites.

E por fim, não se esqueça do infame Quechup que não usa phishing para manipular os usuários visando obter acesso aos seus contatos do Google e fazer spamming para os e-mails da lista. Ele somente pede gentilmente por sua senha e então abusa dela. Eles teriam trocado facilmente umas poucas cargas na sua conta do Google Checkout enquando os usuários tem sorte deles não fazerem.

Um Provedor de Serviços OAuth bem implementado dá aos usuários grande controle sobre o que estão expondo e por quanto tempo. Enquanto OAuth não impede que o Quechup use seus contatos de maneiras que você não permite, ele tornou fácil para o Google simplesmente bloquear as Consumer Keys do Quechup tão logo quanto os reportes de abuso foram chegando, e preveniu assim de mais abusos de API.

Então minha resposta é: “OAuth não treina usuários para permitir phishing – ele treina-os para que não compartilhem seus nomes de usuário e senha com ninguém. E eles nunca devem fazê-lo.”

OAuth – Compartilhando meus estudos

OAuth

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

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.