OAuth är ett autentiserings- och auktoriseringsprotokoll, som ursprungligen utvecklades för webbapplikationer, född i Twitter 2006.

Det gör det möjligt för tredje parts programvara att göra något på din vägnar, under en begränsad tid och utan att ge den programvaran full, permanent tillgång till reserverad information. Den vanligaste analogin är valetangenter.

Låt oss gräva lite djupare och ta reda på mer om OAuth.

F: Så, betjäntangenter. Du menar de nycklar som normalt ges till parkeringskamrater på hotell?

A: Ja. Dessa nycklar gör det möjligt att öppna, starta och köra din bil, men bara för en mycket kort resa och utan att öppna stammen. OAuth fungerar som en valet nyckel för dina data. Det ger tillfällig och begränsad tillgång till något som är ditt, utan att ge full kontroll.

F: Nu förstår jag vad du menar men ... är detta ett verkligt problem i världen?

A: Det blev en när online-tjänster och sociala nätverk i alla sina former, från Twitter och Flickr till avlägsna banker, blev inte bara allestädes närvarande men sammankopplade - de är mycket mer användbara när du kan få dem att fungera tillsammans.

F: Du hänvisar till fall som att publicera ett Flickr-galleri på Facebook.

A: Ja, exakt. Att kunna göra det utan att skriva in allt manuellt är bra. Om du gör det utan något som OAuth kan det emellertid innebära att dessa webbplatser får fullständig åtkomst till alla dina saker (till exempel filer, kontaktlistor eller fullständig tillgång till tjänster).

Fråga: Så därför pratade du om både autentisering och auktorisering?

A: Rätt. Autentisering innebär att du har ett sätt att bevisa att du verkligen är dig. Observera att det i allmänhet inte spelar någon roll om du är en människa eller ett program. Bemyndigande är en separat, lika nödvändig tjänst. Om en person eller ett program har redan visat på Facebook vilka de är, betyder det inte att de har behörighet att uppdatera vår status som om de var oss.

F: Kan inte OpenID har använts för detta?

A: OpenID behandlar endast autentisering. OAuth hjälper istället i alla fall där (med hjälp av OAuth-terminologi) någon programvara (klient) som vill ha tillgång till data på uppdrag av den som har rätt att tillåta sådan åtkomst (resursägare) är helt skild från och okänd för , den programvara eller tjänst som faktiskt lagrar dessa resurser.

F: Vänta en sekund! Någonting som detta var möjligt år före OAuth!

A: Ja, men i de flesta fall innebar det att det bara var ett enda konto för ett nätverk av redan samarbetande webbplatser eller att ge åtminstone en av dem dina användarnamn och lösenord på alla de andra. OAuth försöker stänga säkerhetshålet.

F: Du betyder att du tillåter åtkomst till vad som finns på ett webbkonto utan att ge ut mitt lösenord och användarnamn?

A: Låt oss anta att du kommenterade någon blogg och vill att den bloggen ska skicka den till Twitter på dina vägnar, för att spara skrivning. När du berättar bloggens mjukvara för att göra det här (till exempel genom att klicka på en knapp) skickar den en begäran till Twitter, som innehåller en identifieringsnyckel och listan över data eller tjänster som den vill ha åtkomst till för din räkning. Twitter (inte bloggen!) Kommer att presentera dig ett anpassat webbformulär för behörighet som finns på sin server. Om du loggar in framgångsrikt på Twitter och svarar "ja" på den begäran, har du behörig Twitter för att tillgodose begäran från den bloggen. Utan att överlämna ditt lösenord och användarnamn.

Q: Cool! Sen då?

A: Twitter kommer att berätta för din webbläsare att gå tillbaka till bloggen, men med en särskild URL som innehåller en "access token" eller en enda behörighetsnyckel. Då kommer bloggprogrammet att kunna presentera den token på Twitter, som ett bevis på att det är den som bara har ditt tillstånd att göra något med eller med ditt konto.

F: Och detta kommer att fungera med alla OAuth-kompatibla webbplatser, inte bara Twitter?

A: Det är korrekt. Så länge som dessa webbplatser inte avvisar den ursprungliga begäran, såklart. Förutom bekvämlighet för slutanvändaren var en annan kraftfull drivrutin för OAuth önskan att göra livet svårare för spambots och andra skadliga applikationer.

Fråga: Hur skulle OAuth göra det?

A: Oavsett användarbehörighet kan ett program endast fungera som beskrivet om det har tillstånd att göra det från den webbplats som den vill ha tillgång till. OAuth åstadkommer detta genom att använda flera identifikationsnycklar eller referenser parallellt.

F: Vad är dessa uppgifter och vem som utfärdar dem?

A: Den som vi redan har nämnt, som brukade förklara att åtkomst från något program är tillåtet utan att ge ditt lösenord till det, kallas token-referenser. Innan du kommer till den punkten måste dock kunden ha skickat till sina servrar sina giltiga klientuppgifter.

I allmänhet utfärdas de av webbservern själv. När utvecklarna av viss programvara vill lägga till OAuth-funktioner till det, registrerar de sig med servern för att få sådana uppgifter eller nycklar. Det gör det lite lättare att stoppa vissa skadliga program, men bröt också mycket av befintliga program.

F: Du fortsätter att tala om webbplatser. Betyder det att OAuth är oanvändbar av stationär programvara?

A: Nu är det en knepfråga. Tekniskt finns det inget i OAuth som förhindrar att kunderna är traditionella stationära program som körs inuti din dator. I praktiken gör det (åtminstone med OAuth 1.0) antingen livet svårare för utvecklare av god tro, eller hela konceptet för klientinformation är nästan värdelöst. Särskilt när man använder öppen källkodsprogramvara.

Fråga: Argh! Nu är det dåligt, men varför?

A: Eftersom det beskrivna systemet fungerar perfekt när klientuppgifterna är inbäddade i källkod och / eller kompilerade program som bara körs inuti en webbserver, där ingen kan läsa referensuppgifterna i källkoden eller använda hexredigerare och liknande verktyg, i körbara filer.

Fråga: Är det här varför problemet är ännu större med öppen källkodsprogramvara?

A: Exakt. Om du sätter något som borde vara privat i någon källkod som alla har rätt att ladda ner och studera ... det är inte privat per definition, är det?

F: Visst, men det här gör bara systemet mindre användbart. Varför sa du också att OAuth bryter mot befintlig programvara?

Svar: För innan OAuth 1.0 kan någon med grundläggande kunskaper om skalskript och cUrl (inklusive dina verkligen!) På några minuter få om ett skript som automatiskt skulle logga in på Twitter, att läsa en tidslinje eller posta en tweet. OAuth gjorde det omöjligt utan giltiga, registrerade klientuppgifter. Även när man får dessa referenser tar det mycket längre tid än att skriva manuset i första hand!

F: Finns det inget sätt att lappa dessa skript?

A: Det är självklart: använd bara ett av de många programbibliotek som redan har registrerats. Det gör dock fortfarande de här skriptna mycket mer komplicerade att skriva och underhålla än vad de brukade vara. Innan OAuth 2.0 släpps, åtminstone.

F: Du menar att det finns en version 2.0 som kommer? När?

A: Prognosen, medan vi skriver, är att OAuth 2.0 ska vara färdig i slutet av 2011.

Fråga: Vad är nytt i OAuth 2.0? Kommer det att lösa dessa problem?

A: Det kunde det. En av de viktigaste förändringarna är tillägget eller omdefinitionen av flera så kallade "flöden" för att få inloggningsuppgifter på det enklaste sättet, även i scenarier där klienter inte är webbservrar, men till exempel programvara som körs på mobila enheter. Det finns också ett cookie-baserat flöde som ska göra det möjligt att återuppliva de gamla CURL-baserade webbautomatiseringsskripten. Det bör också finnas flera prestationsoptimeringar, eftersom OAuth 1.0 inte skala mycket bra.

Fråga: Var kan jag få veta mer?

Den officiella OAuth-introduktionen.