OAuth (indsæt bandeord)

Af 7

Der er få ting, jeg har bandet så meget over for nylig som OAuth. Naivt havde jeg troet, at hvis man satte sig ned og RTFM (OAuth-specifikationen i dette tilfælde), så kunne man én gang for alle skrive noget kode, der kunne guide en bruger igennem genereringen af et sæt access tokens og derefter forbinde til web services beskyttet af OAuth ved brug af disse access tokens.

Jeg mener, har man set én web service, der bruger basic auth, har man stort set set dem alle - klart, at OAuth-protokollen har flere (danse-)trin end basic auth, men så længe disse trin var de samme på tværs af udbydere og services, var det noget kode, man kunne skrive en gang og derefter tage sig en velfortjent morfar-lur.

Endda findes der venlige mennesker derude, som har lavet kode-biblioteker, der burde kunne klare ærterne i de fleste populære programmeringssprog. Først forsøgte vi os ad med det Java-bibliotek, der stod øverst på listen hos oauth.net; det skulle oveni købet kunne integrere med Apache HTTPClient, hvilket i vores tilfælde ville være særdeles nyttigt. Men efter en del forgæves forsøg på at kunne forbinde til bl.a. Twitter, kastede vi os over Scribe, der stod omtalt som “a mature OAuth library”. Det var så “mature” i betydningen “afdanket”, tror jeg. Mange af eksemplerne (der ellers var ganske pæne og nemme at forstå) virkede ikke længere - formodentlig fordi de services, de skulle forbinde til, havde ændret sig; eksempelvis opgraderet deres OAuth-understøttelse fra 1.0a til 2.0 (på trods af, at denne standard endnu kun er i “draft”).

Efterhånden er det gået op for mig, at alle service-udbyderne (Twitter, Facebook m.fl.) har deres egen implementation af OAuth med hver sin lille krølle. Hos Facebook skal man f.eks. liiige bruge en anden authorization URL, hvis man sætter et scope på sin request, og Google bruger en helt særlig URL-værdi for callback’et, hvis det skal være out-of-band - hvorfor dog holde sig til “oob” som de andre, når man kan skille sig ud ved at bruge “urn:ietf:wg:oauth:2.0:oob” i stedet? Flere af dem leverer også kun meget kortlivede access tokens, som man skal bruge et refresh token til at generere nye af, og de har naturligvis igen forskellige måde at aflevere den refresh token på, hvilket det føromtalte Scribe-bibliotek heller ikke har taget højde for.

Så executive summary på mine OAuth-erfaringer indtil videre er, at man skal regne med at hånd-kode en hel del for hver eneste API-udbyder, man vil forbinde til - uanset om de påstår at anvende samme version af standarden - samt at jeg pt. er blevet noget skeløjet af at forsøge at tyde udvikler-dokumentationen hos Google, Facebook m.fl. Mange gange gemmer hemmeligheden om, hvorfor ens implementation ikke virker, sig i en tilsyneladende udbetydelig bemærkning et tilfældigt sted i et meget lang manual.

Jeg kan vist ikke sige det bedre end Karsten Strøbæk:
OAuth. #$.|<#%>$~ Sigh ...

Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Steen Eugen Poulsen

Jeg har altid fundet Unix inspireret software interessant fordi de har config filer, hvor en vær idiot med en tekst editor kan rette i for at få et eller andet non-standard til at virke.

Jeg vælger altid at skrive et config fil system, i stedet for at hardcode, da jeg føler det på længere sigt spare tid og penge også selvom der er til et system med mindre rod i standarderne, der er altid en eller anden der for standarden galt i halsen, så er det nemre lige at sætte en student til at lave en config fil opdatering and at betale en million for en programmør skal omskrive programmet.

  • 1
  • 6
#2 Bjarke Walling

... at der er så mange at vælge imellem.

Jeg har selv implementeret dele af en specifik revision af OAuth 2 draft i et system, så jeg bidrager til problemstillingen. OAuth 2 er simplere designet end OAuth 1, hvilket gør den til et nemt valg til trods for draft-status. Vi har implementeret de grant types vi har brug for (efter tankegangen YAGNI - you ain't gonna need it). Man kan håbe på at der ikke går lang tid før OAuth 2 draften bliver recommendation, og API-udbydere retter ind efter den.

Er der nogen, der vil lave (og promovere) en online OAuth validation service? Bare en idé. :-)

Bjarke Walling, Digroli

  • 1
  • 0
#3 Peter Mogensen

Det burde nu ikke overraske, burde det? Når jeg læser om OAuth, så er alt hvad der hedder noget <2.0 lige til at smide ud fordi 2.0 alligevel genopfinder alting. Og 2.0 er - som du nævner - stadig i draft og så vidt jeg kan se er der sket store ændringer i det draft på det sidste, så det burde vel ikke overraske at alle disse eksperimentielle implementationer du ser hos dem, der driver OAuth 2.0 initiativet ikke opfører sig helt som den endelige standard kommer til?

Mao... du bruger en standard, der ikke er færdiglavet.

  • 1
  • 1
#5 Deleted User

Hej Sofie

I den næste fremtid, havde jeg også tænkt mig at implementerer Facebook og Twitter login på vores løsning, men efter at havde læst din blog, er jeg blivet overbevist om at jeg nok skal uddelegere jobbet til en service som f.eks. Janrain.com (Nogle der kender alternativer ?) Jeg synes også det udløser en morfar, at havde uddelegeret den kode der skulle skrives og vedligeholdes til en service :-)

  • 0
  • 0
#6 Anton Stonor

Hej Peter,

Jeg har selv leget lidt med Velruse (https://github.com/bbangert/velruse), der kan køre som en lokal authentication-normaliserings-tjeneste, så ens app ikke behøver at forhold sig til, om der er tale om Facebook, Twitter, Google mm. Virker OK.

Alternativt kan man jo få inspiration fra Velruse-koden til at håndtere diverse OAuth-krøller.

PHP-brugere kan måske have gavn HybridAuth (http://hybridauth.sourceforge.net/).

  • 0
  • 0
#7 Mark Gjøl

Jeg har selv måttet lave OAuth mod Facebook, Google og Flickr. Flickr er klart den mest behagelige, og deres eksempler er præcis lavet så jeg bliver glad (der er endda en fin side hvor man kan klikke sig frem til et request, og så få request + response). Med Google endte jeg med at give op, og måtte ty til signpost ( http://code.google.com/p/oauth-signpost/ ). Google bruger vist ikke så meget tid på at dokumentere deres ting, hvorfor det sjældent er den tydeligste tekst du vil støde på.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen