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