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.”
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.