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.

 

Resenha – Getting Real

Getting Real

Hoje venho falar de outro excelente livro que acabei de ler recentemente, o Getting Real, da empresa de software 37signals. Apesar de conseguir ler em inglês com facilidade, acabei encontrando o dito-cujo gratuitamente e em português no site da empresa mesmo. Uma galera brasileira traduziu o livro e a empresa resolveu disponibilizá-lo gratuitamente na web. O livro é sensacional e abaixo compartilho um pouco das nuances do mesmo.

A Empresa

Tive meu primeiro contato com a 37signals no excelente livro Startup, da autora Jessica Livingston, que como o próprio nome sugere, conta a história de diversas startups de sucesso, incluindo Yahoo, Apple, Adobe, etc. A 37signals está na lista do livro e ao longo dos anos fui descobrindo mais e mais coisas bacanas sobre a empresa, que na minha opinião, é uma das empresas mais cool que alguém poderia trabalhar em termos de ambiente de trabalho e projetos legais.

Atualização em 20/04/17: essa empresa agora se chama Basecamp, em alusão ao seu produto mais famoso.

A 37signals é o tipo de empresa pequena que fatura grande, no melhor estilo lifestyle business, mas sem deixar de ser uma startup. Eles trabalham com desenvolvimento de software web em equipes pequenas e de alto desempenho, semelhante ao que o Scrum prega. Entenda alto desempenho como equipes com poucas pessoas mas altamente capacitadas, com anos de experiência, muita criatividade, boa lógica e que dominam não somente código mas interface. Deve ser bem difícil para os caras encontrarem gente assim…

Entre os produtos da empresa está o famoso BaseCamp, um anti-MS Project online, muito mais simples e intuitivo. Mas para mim este não é o projeto mais interessante da empresa, mas sim o framework Rails, para a linguagem de programação Ruby. Se hoje tem uma galera se divertindo programando Ruby on Rails é graças aos caras dessa empresa (mais especificamente o DHH) que desenvolveu o framework original e abriu pra galera contribuir. Muito fera.

O Livro

A 37signals tem anos de mercado e um jeito peculiar de trabalhar e encarar seus projetos. Neste livro eles mostram o seu método de trabalho, que eles chamam de Getting Real (Caindo na Real), um método extremamente prático, dinâmico e ágil. Eles pregam muitos itens que já li no Scrum Guide, já aprendi no curso de Professional Scrum Developer e entre tantos outros lugares que falam de metodologias ágeis (como XP).

O livro não existe oficialmente em português (até onde sei) mas tradutores autorizados pela empresa traduziram pro portuga e disponibilizaram tudo em um link dentro do site da própria empresa. Sim, isso mesmo. Você podem conferir o livro na íntegra em http://gettingreal.37signals.com/GR_por.php.

O que eles ganham com isso?

De onde eles tiram o lucro em um livro distribuído gratuitamente?

Chris Anderson explica isso muito bem em sua obra intitulada Free: O Futuro dos Preços. Dar o seu livro Getting Real faz com que as pessoas tenham acesso a inúmeros benefícios intelectuais e em troca proporcionam alguns ganhos à 37signals, que em um primeiro momento não são monetários.

O primeiro deles é o conhecimento da empresa. Em um mercado de Googles e Microsofts fica difícil conseguir “aparecer” na mídia, e dar um ótimo livro de graça faz com que as pessoas tenham mais simpatia pela sua empresa (eu mesmo faço isso com o livro Meu primeiro app Android).

Segundo, na página do livro tem links para que você possa comprá-lo impresso ou em PDF, lhe poupando os olhos de ler no LCD do PC, hehehehe.

Terceiro, na página do livro você vê um banner de propaganda do site de emprego deles, e acaba ficando curioso por conhecê-lo (eles cobram das empresas anunciantes pelo serviço de postar vagas lá).

Quarto, no livro eles falam sobre quase todos os seus produtos, o que pode ser considerado um “jabá” do caramba, mas que se encaixa bem como exemplo da utilização bem-sucedida de seus métodos, e a menção dos mesmos desperta curiosidade por conhecê-los.

E por último, no Getting Real eles fazem menção ao Rework, o seu mais novo livro que não existe disponível na Internet, apenas comprando tradicionalmente.

Sendo assim, em nenhum momento eles perdem dinheiro uma vez que dificilmente o povo brasileiro teria acesso à essa obra ou sequer conhecimento da mesma e o custo da tradução (voluntária) e distribuição (Internet) são gratuitos. E aí, será que eles tem prejuízo com a disponibilização online do livro?

A Resenha

Resumidamente, o livro é muito bom.

E quando eu falo muito bom não é pouca coisa porque sou chato pra caramba com livros. Extremamente aplicável, os conceitos apresentados no livro são um balde de água fria nos métodos tradicionais de engenharia de software, principalmente quando estamos falando de software web. E não estamos falando de teóricos anarquistas querendo apenas causar impacto nos leitores. Estamos falando de uma empresa altamente rentável compartilhando suas experiências e metodologias com os outros, gratuitamente.

Dividido em capítulos curtos, com linguagem coloquial e cheia de depoimentos de outras pessoas que “caíram na real”, a leitura é prazerosa e rápida. Leia um capítulo enquanto que pega o ônibus ou metrô para ir para casa. Leia outro antes de dormir. No intervalo do almoço. Cada seção detalha como “cair na real” em um aspecto diferente dos seus projetos, desde o planejamento, o desenvolvimento, o lançamento, o “beta”, os bugs e por aí vai.

Eu passei esse link para o pessoal do meu serviço e todo mundo que teve a oportunidade de ler um ou dois capítulos adorou o livro, incluindo nosso CEO, que não mete mais a mão na massa nos softwares há anos.

Getting Real obviamente possui muitas coisas que você não vai concordar. E esse não é objetivo do livro, eles não se consideram uma “bala de prata”. Na verdade nenhuma metodologia devia ser encarada como “verdade universal”. Getting Real é para instigar os leitores a melhorarem seus processos. A encararem seus problemas de frente. Melhorarem a comunicação de sua equipe. Diminuírem os custos e prazos de seus projetos. É dar aos usuários o que eles precisam e não o que eles acham que precisam. É sobre ser um profissional melhor.

Fecho essa curta resenha com um dos parágrafos mais marcantes do livro, que caracteriza bem a forma como vejo meu trabalho e de mais alguns colegas aqui na RedeHost:

“Você precisa de pessoas que são apaixonadas pelo que fazem. Pessoas que se importam pelo seu artesanato – e que realmente acham que é um artesanato. Pessoas que se orgulham do seu trabalho, independentemente da recompensa monetária envolvida. Pessoas que suam nos detalhes mesmo que 95% das pessoas nem saibam distinguir as diferenças. Pessoas que querem construir alguma coisa grande e não se conformam com menos. Pessoas que precisam de pessoas. Ok, não necessariamente essa última coisa mas não iríamos resistir não jogar um pouco de Streisand na mistura. De qualquer forma, quando encontrar essas pessoas, segure-se nelas. No final, as pessoas da sua equipe farão ou quebrarão seu projeto – e sua empresa.”

Se esse parágrafo lhe parece uma “história pra boi dormir” (a.k.a. “conto da carochinha”), então esse livro não é para você. Se isso é a sua realidade ou você gostaria que fosse, não perca tempo e acesse este link, afinal, o que você tem à perder?

Treinamento em ASP.NET e SQL Server na Facensa

Boa tarde aos incríveis 7 leitores do blog. Seguindo meu cronograma mental de posts, hoje eu venho falar da minha experiência como instrutor na instituição Facensa, a Faculdade Cenecista Nossa Senhora dos Anjos em Gravataí. Ou a “Faculdade do Gensa” como o pessoal da região costuma chamar. Graças à indicação de meu colega Cristiano “Mato-Fino” Diedrich (esses caras do software livre adoram apelidos estranhos…) entrei em contato com o Prof. Ms. Marcelo Batista, um dos maiores entusiastas em tecnologia e educação que tive o prazer de conhecer em Gravataí. E assim começou uma parceria bem maior do que esperávamos enquanto empresa.

Case Facensa: janeiro de 2011

Sim, isso mesmo. O treinamento na Facensa foi em plena férias de verão. Quem acha que isso foi maldade com os alunos levanta a mão! Na verdade as negociações para o treinamento surgiram antes, mas como o calendário se sobrepunha ao do treinamento da FAQI e eu sou um só, tivemos de adiar. Obviamente não pulamos nenhuma etapa, tendo realizado nossa palestra sobre a RedeHost ainda em 2010 em meio a um simpósio (é essa a palavra?) de computação na própria Facensa para em seguida marcarmos o dia da famigerada prova de lógica, agora em sua versão 1.1.

Entre os que passaram na prova, tive o prazer de lecionar meu “cursinho” para 14 alunos da instituição, que, embora a nota de corte fosse 5 na prova, obtiveram média geral 7, o que considero uma ótima nota conhecendo a prova que aplico. Os encontros dessa vez foram em outro formato, ao invés de uma aula semanal, tínhamos aula todas segundas e sextas-feiras em um excelente laboratório da universidade (ok, o teclado era no mínimo estranho) com exercícios práticos como “tema de casa” durante a semana. Entre mortos e feridos, cada um com seus problemas, terminamos o curso com 9 alunos, em sua maioria devidamente preparados para o mercado de desenvolvimento ASP.NET.

Treinamento ASP.NET Facensa

Resultados

Como obviamente meus treinamentos não são apenas pelo prazer de lecionar (embora isso ajude bastante) sou obrigado a mostrar resultados para minha chefia. Dessa vez consegui uma excelente contratação que prefiro manter anônima embora o Prof. Marcelo adore usá-lo como “case de sucesso” da parceria RedeHost-Facensa e fazê-lo passar vergonha em plena aula mostrando a todos quem ele é, hehehehehehe. Acima tem uma foto tirada no primeiro dia de aula, e apesar de eu estar parecendo um abobado falando sozinho, é a melhor foto dentre as que o CPD da Facensa me conseguiu…fazer o quê, sou programador e não modelo XD

Conclusão

A Facensa e a RedeHost firmaram parcerias que já renderam alguns frutos e muitas outras novidades ainda virão. O Prof. Marcelo e nosso CEO, Flávio Cardoso, tem muitos planos envolvendo pesquisa e fomento de tecnologias que serão úteis à RedeHost e à própria comunidade gravataiense em geral. É esperar para ver. Eu mesmo mantenho contato constante com o Prof. Marcelo, uma vez que ingressei no Mestrado e futuramente espero me tornar um professor de verdade. Afinal sempre é bom ter um mentor mais experiente lhe ajudando a seguir o caminho certo. E já temos a idéia de repetir a dose na própria instituição: em julho de 2011, em plena férias de julho, faremos com que mais uma turma de alunos não possa se divertir nas férias. Uhu! Interessados já podem começar a incomodar o prof. desde agora. Em breve mais novidades sobre os próximos treinamentos!