Have you ever wondered how you can display email and calendar events from Google in your own web site? Or how you can log in to your site using your Google account? Both staff and students at Norwegian School of Information Technology (NITH) use GMail and Google Calendar for internal communication. They hired BEKK to implement a new web site and intranet application. One of the features they wanted was GMail and Google Calendar integrated into their intranet, with a custom visual styling.

To achieve this we decided to use Google’s OpenID+OAuth hybrid protocol – a  draft specification proposed by Google.

OpenID is an open standard for web site authentication. An OpenID consumer web site (for example an intranet or a wiki) can delegate user authentication to a centralised OpenID provider web site (for example MyOpenID.com or Google). This means less usernames and passwords to remember for end-users and single-sign-on (SSO) becomes easy to implement.

OAuth is an open standard for web site authorisation. This lets an OAuth consumer web site send and retrieve private information to/from an OAuth provider web site on behalf of an end-user.

NITH was kind enough to let us share some of the code we developed for them to illustrate how all of this works. The result is a simple web application that you can try out with your own Google account. The source code is available under the MIT license and you can download it from GitHub. Both the sample application and the NITH.no site are hosted on Heroku, a top-notch hosting provider for Ruby on Rails running on top of Amazon’s EC2 cloud. The applications are written in Ruby on Rails, but you can easily implement similar functionality on other platforms such as JEE, .NET, PHP etc using freely available OpenID and OAuth libraries.

Let’s first look at the user workflow. (The workflow illustrated here is a slight modification of how NITH’s intranet works).

1) The user follows the Login link on the front page of the consumer application.

2) The user is redirected to Google’s login page and logs in (OpenID authentication).

3) The user authorises the Intranet application to access GMail and Google Calendar (OAuth).

4) The user is redirected back to the consumer application which displays GMail and Google Calendar.

If the user checks the “remember me” checkboxes, step 2 and 3 will be skipped in the future.

If you want to implement a similar integration with Google in your own application, here are the main steps:

Register your domain at Google

Google’s OAuth service requires any OAuth consumer to be pre-registered before it can use the service. To do this, go to Google’s Domain registration page and register information about your site. You only have to register the domain name.

Google will then provide you with a static HTML file that you must serve from your domain. When you have uploaded this HTML file, click “verify domain” on Google’s registration page.

Use your OAuth consumer secret

When you register your domain with Google, you will also be given an OAuth consumer secret (a simple String token) that your consumer application must use when connecting to Google. This consumer secret is bound to the domain name, so it cannot be used from any other host, including localhost.

Find an OpenID library that supports Google’s OpenID+OAuth hybrid protocol

This is the hardest part. The natural choice for a Rails application using OpenID is to use the “official” ruby-openid library. However, this library doesn’t support the hybrid protocol, so we had to use Aslak’s fork of Pelle Braendgaard’s ruby-openid fork. We also had to use Pelle’s slightly modified fork of Rails’ open_id_authentication library.

Until the OpenID+OAuth hybrid protocol becomes an official extension to the OpenID protocol you will not find support for it in all OpenID libraries, but they are all open source – so you have the freedom to add this yourself. Open source wins again.

Summing up

OpenID and OAuth are supported by an increasing number of libraries and web sites. Google is by no means the only site supporting the protocols (and to be honest – Google’s implementation deviates a little from the standard). If you are considering implementing some kind of single sign on we recommend you consider these protocols.

Folk flest, meg selv inkludert, har et stadig økende antall kontoer rundt omkring på nettet. Passord er vanskelig å huske og derfor har man en tendens til å bruke et enkelt et som er felles for alle disse kontoene som man signer opp på helt ukritisk. Eller man prøver å ha forskjellige og gode passord, men glemmer dem med en gang man trykker SignUp-knappen. Så hvorfor ikke bruke et brukernavn og passord som man allered har? Både Facebook (FB) og Twitter har funksjonalitet som lar eksterne nettsteder bruke dem som en såkalt “delegated sign-in provider”. La oss se litt på hvor enkelt det er å ta i bruk.

Facebook Connect

Facebook Connect er en tjeneste fra FB som lar deg gjøre flere ting, som f.eks. identitetssjekking, linking til FB-venner, FB-deling og autentisering.

Autentiseringen kan integreres i andre nettløsninger og logger inn brukerne med fire enkle steg:

1. Når en bruker går til nettsiden, kan man bruke FB Connect sitt javascriptbibliotek for å sjekke om brukeren allerede er logget inn på FB
2. Hvis det er tilfellet kan man enten redirecte brukeren til et “innlogget”-view eller oppdaterer siden inline med Javascript (sikkert det smootheste)
3. Hvis brukeren ikke er logget inn kan man enten vise på den nåværende siden eller redirecte til en egen loginside
4. Når trykkes starter login-prosessen og den vil i sin tur igjen kalle et javascript-callback som man har registrert

Og det var det!

FB Connect kan brukes direkte i en hel bråte programmeringsspråk via forskjellige klientbiblioteker (både offisielle og tredjeparts). Jeg nevner i fleng Java, Python, Ruby on Rails, og til og med Lisp og Erlang.

Nettet florerer med nettsteder som bruker Facebook Connect enten som bare autentisering eller også med mer avansert FB-funksjonalitet, men posterous og den nye diggbar er gode eksempler på en velykket integrasjon.

Som om ikke det var nok har FB blitt medlem av OpenID Foundation og støtter OpenID-innlogging med kontoer fra bl.a. Google, Yahoo og Myopenid.

Se Facebooks dokumentasjon for flere detaljer

Logg inn med Twitter, OAuth-Style

Twitter er heller ikke dårligere enn at de har lansert sin egen delegerte login-løsning, Sign-in with Twitter.

I motsetning til Facebooks løsning som er proprietær, er dette helt standard OAuth.OAuth er i følge oauth.net:

An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.

Måten man blir logget inn på er så og si identisk med den 4-stegsprosessen beskrevet i avsnittet om Facebook så jeg skal ikke repetere det, og i praksis kan man bruke dem på samme måte og i samme løsning.

Twitters løsning har nok alle de tusenvis av tredjeparts twitter-applikasjoner og -nettsider som finnes som hovedmålgruppe, og autentiseringen er en innebygget del av det åpne API’et som brukes ved utvikling av slike tredjeparts-tjenester. Eksemplene under på løsninger som bruker Twitter OAuth er også twitterrelaterte.

DestroyTwitter

twitpic

Edit:

Jeg ble spurt om følgende av en kollega i et annet fora:

“Bruker destroytwitter og twitpic egentlig oauth? Mulig jeg har misforstått, men jeg trodde hensikten var at en tredjepart ikke skulle motta passordet i det hele tatt.”

Og svaret er: Nei dessverre ikke! Disse to tjenestene bruker ikke OAuth, de benytter seg bare av muligheten i Twitters API til å logge inn utenfra med brukernavn og passord.

Det er ikke så lett å finne “real life”-eksempler på nettløsninger som bruker Twitters OAuth slik den skal, men min favoritt microblog-tjeneste posterous
har også denne innenfor beltet.

posterous.com bruker ekte Twitter OAuth

Min kollegas (berettigede) frykt for løsningene DestoryTwitter og twitpic bruker:

“Jeg liker ikke å oppgi passordet for en tjenteste til andre tjenester. Da går man lett i phishing-fella.”

Denne artikkelen på blogen til Cris Messina forklarer på en meget god måte hvorfor det er en dårlig idé å bruke login-integrasjon hvor brukeren må oppgi brukernavn og passord til en tredjepart.

Twitters API har en egen wiki hvor det står mer om Twitter OAuth.

Gjør det enklest mulig for brukeren

Konklusjonen blir, enten man velger Facebook Conect, Twitter OAuth, OpenID eller alle tre, at en slik delegert login-løsning forbedrer brukeropplevelsen. Man synes det er lettvint og trygt å logge seg på via en kjent logo (f.eks. Facebook). Kanskje man til og med senker terskelen for å faktisk opprette en konto på nettop dette nettstedet og ta dets tjenester i bruk. Og det er jo nettopp det vi som utviklere ønsker og oppnå!

Kilder og ressurser

• tvitre.no
• checkfacebook.com
• http://www.hueniverse.com/hueniverse/2009/04/twitter-connect.html
• http://wiki.developers.facebook.com/index.php/Authenticating_Users_with_Facebook_Connect
• http://wiki.developers.facebook.com/index.php/Client_Libraries
• http://posterous.com
• http://digg.com/tools/diggbar/
• http://openid.net/
• http://oauth.net/
• http://destroytwitter.com/
• http://twitpic.com/
• http://apiwiki.twitter.com/
• http://factoryjoe.com/blog/2009/01/02/twitter-and-the-password-anti-pattern/

• OpenID støtte for en samlet digital identitet
• Epost kontroll (sjekke at brukeren virkelig eier en gitt adresse)
• Passord administrasjon
• Globale utlysninger
• Rammeverk for å sende beskjeder til brukere
• Bruker-til-bruker meldinger
• Invitasjon av venner (både eksternt og internt)
• Twitter mikroblogg klon
• Oembed støtte for å integrere objekter fra tredjeparts sider (Flickr bilder, Youtube videoer, presentasjoner fra 280slides, osv.)
• Gravatar støtte for globale avatarer bunnet til din epost adresse.
• Interessegrupper (tribes)
• Prosjekter med oppgaver og oppgavelister
• Diskusjoner
• Wiki
• Blogging
• Bokmerker
• Tagging
• Kontakt import fra vCard, Google eller Yahoo
• Bildeadministrasjon
• Geografisk plassering av brukere

Når man bruker Pinax kan man derfor velge hvilke av disse applikasjonene man vil bruke basert på hva slags funksjonalitet man ønsker å eksponere sine brukere for. Med en slik sammensying av applikasjoner vil man forhåpentligvis ha et godt utgangspunkt for å kunne implementere de elementene som skiller ditt sosiale nettsted fra alle andre.

I denne artikkelen vil vi gi en installasjonsbeskrivelse av Pinax og en beskrivelse av hva dette produktet tilbyr “out of the box”. I senere artikler vil vi kunne beskrive hvordan man både tilpasser Pinax og utvider plattformen.

Forutsetnginger

Pinax og dens avhengigheter installeres enklest på en UNIX-basert plattform. Vi vil i denne introduksjonen fokusere på Debian GNU/Linux, men plattformspesifike inststruksjoner kan lett oversettes til andre Linux distribusjoner eller operativsystem  som Ubuntu, Fedora, FreeBSD eller OS X.

Man bør ikke være redd for kommandolinjen da mesteparten av installasjonsprosessen vil foregå her. I tillegg kan det være nyttig å kjenne til progammeringsspråket Python samt rammeverket Django som begge er brukt for å utvikle Pinax.

Installasjon

Pinax sin egen kode samt enkelte av dens avhengigheter finnes direkte i versjonskontrollsiloer. Man må derfor installere Subversion og Git:


apt-get install git-core subversion


Pinax krever at man har Python installert samt en database for å kunne lagre innhold. Sqlite er enklest å bruke under uttesting:


apt-get install python sqlite3

Deretter lager vi en folder (vi har kalt den pariter) hvor vi kan installere Pinax samt alle avhengigheter:


mkdr pariter


Deretter laster vi ned og starter installasjonen av Pinax ved hjelp av at bootstrap script:

cd pariter
http://svn.pinaxproject.com/pinax/trunk/scripts/pinax-boot.py


python bootstrap.py pinax


Dette har gitt oss Pinax (uten spesifikke applikasjoner) samt Django. Disse har blitt installert i et virtuelt miljø. For å bruke Pinax må man derfor aktivere dette miljøet for hver sesjon:


cd pinax
source bin/activate


Pinax bruker pip som verktøy for å installere eksterne pakker utenom Pinax selv og Django.  Man bruker enkle tekstfiler som beskriver hvor disse avhengighetene finnes og eventuelt hvilke versjoner man vil bruke. Pinax kommer med en slik fil som er satt opp til å hente alle avhengigheter inklusive de ulike applikasjonene som bygger opp Pinax sin funksjonalitet. For å installere alle disse gjør man som følger:


pip install -r src/pinax/requirements/external_apps.txt

Installasjonen av alle avhengighetene kan ta en del tid. Hvis man får feilmeldinger underveis (mest sannsynlig på grunn av nettverksproblemer) er det bare å starte prosessen igjen. Den eneste avhengigheten som ikke blir installert med pip er PIL (Python Imaging Library). Dette gjøres heldigvis enkelt i Debian med apt-get:


apt-get install python-imaging


Pinax kommer med flere ferdiglagede prosjekter som setter sammen flere eller alle av Pinax sine applikasjoner. Man kan basert på disse prosjektene lage sine egne og velge akkurat hva slags funksjonalitet man velger å tilby.

Vi vil nå teste ut et fullstendig prosjekt som inkluderer alle applikasjonene til Pinax. Det kan være lurt å gjøre dette først for å danne seg et bilde av hva slags funksjonalitet Pinax kan tilby og dereter luke ut det man ikke har behov for. Dette fullstendige prosjektet finner man i Pinax sin kildekode som ble lastet ned i bootsrapp prosessen i begynnelsen av installasjonen:


cd src/pinax/pinax/projects/complete_project


I denne folderen finner man manage.py, et script som håndterer det meste av interaksjonen med Pinax. Denne filen er standard for alle Django prosjekter. Siste steget vi må utføre før vi kan starte opp Pinax er å sette opp databasen med initiell data og tabellstrukturer:


python manage.py syncdb


Man vi bli spurt om man vil opprette en superbruker for denne installasjonen av Django/Pinax. Skriv yes og følg instruksjonene for å gjøre dette.

Når databasen er ferdig satt opp er det bare å starte Pinax. Vi bruker en HTTP server som kommer med Django for å lett teste ut prosjektet vi nå har satt opp:


python manage.py runserver

Serveren lytter nå på port 8000. Åpn opp din favoritt nettleser og gå til http://localhost:8000. Under vil du finne utvalgte skjermskudd av en standard Pinax installasjon.

Man kan logge på eller registrere både med tradisjonelt brukernavn og passord eller OpenID

Etter registrering blir man tatt til en velkomstside som informerer deg om de neste stegene du kan ta for å involvere deg i siden

Navigasjonen med alle applikasjoner installert har en tendens til å bli litt uryddig

Man får beskjed om forskjellige hendelser som bruker av nettsiden og har også mulighet til å styre hva man vil bli påminnet om

Man kan laste opp bilder samt gi de tagger og kommentarer

En liten Twitter klon har også fått plass i standardapplikasjonene

Man har mulighet for å indentifisere hvor man befinner seg geografisk ved hjelp av søk og kart

Pinax er i varierende grad oversatt til en håndfull språk