OAuth é um protocolo de autenticação e autorização, originalmente desenvolvido para aplicações web, nascido dentro do Twitter em 2006.

Ele permite que softwares de terceiros façam algo em seu nome, por um tempo limitado e sem dar a esse software acesso completo e permanente a informações reservadas. A analogia mais comum é as chaves de valet.

Vamos nos aprofundar um pouco mais e descobrir mais sobre o OAuth.

Q: Então, chaves de valet. Você quer dizer aquelas chaves normalmente entregues a atendentes de estacionamento em hotéis?

Um: sim. Essas teclas tornam possível abrir, ligar e dirigir seu carro, mas apenas por uma viagem muito curta e sem abrir o porta-malas. OAuth funciona como uma chave de valete para seus dados. Dá acesso temporário e restrito a algo que é seu, sem dar controle total.

Q: Agora, eu entendo o que você quer dizer, mas ... isso é um problema do mundo real?

R: Tornou-se um quando os serviços online e as redes sociais em todas as suas formas, do Twitter e do Flickr aos serviços bancários remotos, se tornaram não apenas onipresentes, mas interconectados - eles são muito mais úteis quando você os faz trabalhar juntos.

P: Você se refere a casos como a publicação de uma galeria do Flickr no Facebook.

A: Sim, exatamente. Ser capaz de fazer isso sem reentrar tudo manualmente é ótimo. No entanto, fazê-lo sem algo como OAuth pode significar dar a esses sites acesso total a todas as suas coisas (como arquivos, listas de contatos ou acesso total aos serviços)..

P: Então é por isso que você falou sobre autenticação e autorização?

A: correto. Autenticação significa ter uma maneira de provar que você é realmente você. Por favor, note que, em geral, não faz diferença se 'você' é um ser humano ou um programa de software. Considerando que a autorização é um serviço separado e igualmente necessário. Se uma pessoa ou programa de software já provou para o Facebook quem é, isso não significa que eles têm permissão para atualizar nosso status como se fossem nós.

P: Não foi possível usar o OpenID para este?

R: O OpenID lida apenas com autenticação. OAuth, em vez disso, ajuda em todos os casos em que (usando a terminologia OAuth) algum software (cliente) que gostaria de acessar dados em nome de quem tem o direito de autorizar tal acesso (proprietário do recurso) é completamente separado e desconhecido , o software ou serviço que realmente armazena esses recursos.

Q: Espere um segundo! Algo como isso foi possível anos antes do OAuth!

R: Sim, mas na maioria dos casos significava usar apenas uma conta de uma rede de sites já cooperados ou dar a pelo menos um deles seus nomes de usuário e senhas em todos os outros. OAuth tenta fechar essa falha de segurança.

P: Você quer dizer autorizar o acesso ao que está dentro de uma conta da Web sem fornecer minha senha e nome de usuário?

R: Vamos supor que você tenha feito um comentário em algum blog e queira que o blog o publique no Twitter em seu nome, para economizar na digitação. Quando você diz ao software do blog para fazer isso (por exemplo, clicando em um botão), ele enviará uma solicitação ao Twitter, que inclui uma chave de identificação e a lista de dados ou serviços que gostaria de acessar em seu nome. O Twitter (não o blog!) Apresentará a você um formulário da Web de autorização personalizada hospedado em seu servidor. Se você fizer o login com sucesso no Twitter e responder "sim" a essa solicitação, autorizará o Twitter a satisfazer a solicitação desse blog. Sem entregar sua senha e nome de usuário.

Q: Legal! Então o que?

R: O Twitter dirá ao seu navegador para voltar ao blog, mas com um URL especial que inclua um 'token de acesso' ou uma chave de autorização de uso único. Nesse ponto, o software do blog poderá apresentar esse token para o Twitter, como prova de que é ele quem acabou de obter permissão para fazer algo com a sua conta.

P: E isso funcionará com todos os sites compatíveis com o OAuth, não apenas com o Twitter?

A: Está correto Contanto que esses sites não rejeitem a solicitação inicial, é claro. Além da conveniência para o usuário final, outro poderoso driver para o OAuth foi o desejo de tornar a vida mais difícil para spambots e outros aplicativos maliciosos.

P: Como o OAuth faria isso??

R: Independentemente da autorização do usuário, um programa de software pode funcionar conforme descrito somente se tiver permissão para fazer isso no site que deseja acessar. OAuth faz isso usando várias chaves de identificação, ou credenciais, em paralelo.

P: Quais são essas credenciais e quem as emite??

R: O que já mencionamos, aqueles usados ​​para declarar que o acesso de algum programa é permitido sem fornecer sua senha a ele, são chamados de credenciais de token. Antes de chegar a esse ponto, no entanto, o cliente deve ter enviado ao servidor suas credenciais de cliente válidas..

Em geral, eles são emitidos pelo próprio servidor da web. Quando os desenvolvedores de alguns softwares desejam adicionar recursos OAuth, eles registram-se no servidor para obter tais credenciais ou chaves. Isso torna um pouco mais fácil parar alguns malwares, mas também quebrou vários programas existentes.

Q: Você continua falando de sites. Isso significa que o OAuth não pode ser usado pelo software de desktop??

A: Agora essa é uma pergunta complicada. Tecnicamente, não há nada no OAuth que impeça os clientes de serem aplicativos tradicionais de área de trabalho em execução no seu computador. Na prática, fazer isso (pelo menos com o OAuth 1.0) torna a vida mais difícil para os desenvolvedores de boa fé ou o conceito de credenciais do cliente como um todo quase inútil. Especialmente ao usar software de código aberto.

Q: Argh! Agora isso é ruim, mas porque?

R: Porque o esquema que descrevi funciona perfeitamente quando as credenciais do cliente estão embutidas no código-fonte e / ou programas compilados que só correm dentro de algum servidor web, onde ninguém pode ler as referidas credenciais no código-fonte ou, usando editores hexadecimais e ferramentas similares em arquivos executáveis.

P: É por isso que o problema é ainda maior com o software de desktop de código aberto??

A: Precisamente. Se você colocar algo que deveria permanecer privado em algum código fonte que todo mundo tem o direito de baixar e estudar ... não é privado por definição, é?

P: Claro, mas isso só torna o esquema menos útil. Por que você também disse que o OAuth quebra o software existente?

R: Porque antes do OAuth 1.0, qualquer um com um conhecimento básico de shell script e cUrl (incluindo o seu verdadeiramente!) Poderia, em apenas alguns minutos, concluir um script que iria automaticamente entrar no Twitter, ler uma linha do tempo ou postar um tweet. OAuth tornou isso impossível sem credenciais de cliente registradas e válidas. Mesmo quando receber essas credenciais leva muito mais tempo do que escrever o script em primeiro lugar!

P: Não há como corrigir esses scripts??

R: Claro que existe: basta usar uma das muitas bibliotecas de software que já foram registradas. No entanto, isso ainda torna esses scripts muito mais complicados de escrever e manter do que costumavam ser. Até que o OAuth 2.0 seja lançado, pelo menos.

Q: Você quer dizer que há uma versão 2.0 chegando? Quando?

R: A previsão, enquanto escrevemos, é que o OAuth 2.0 deve ser concluído até o final de 2011.

P: O que há de novo no OAuth 2.0? Será que vai resolver esses problemas?

A: Poderia. Uma das mudanças mais importantes é a adição ou redefinição de vários chamados "fluxos" para obter credenciais da maneira mais direta, mesmo em cenários em que os clientes não são servidores da Web, mas, por exemplo, software em execução em dispositivos móveis. Há também um fluxo baseado em cookie que deve tornar possível ressuscitar os antigos scripts de automação da web baseados em cURL. Também deve haver várias otimizações de desempenho, porque o OAuth 1.0 não é muito bem dimensionado.

Q: Onde posso descobrir mais?

A introdução oficial do OAuth.