Share
I en värld som domineras av sociala medier är det svårt att inte komma över en kundansökan som du har använt för att få tillgång till begränsade resurser på någon annan server, till exempel kan du ha använt ett webbaserat program (som NY Times) för att dela en intressant nyhetsartikel på din Facebook-vägg eller tweet om det. Eller du kanske har använt Quoras iPhone-app som åtkomst till din Facebook- eller Google+ profil och anpassar resultaten utifrån dina profildata, som föreslår att du lägger till / bjuder in andra användare till Quora, baserat på din vänlista. Frågan är hur kan dessa applikationer få tillgång till dina Facebook-, Twitter- eller Google+ konton och hur kan de få tillgång till dina konfidentiella uppgifter? Innan de kan göra det måste de presentera någon form av autentiseringsuppgifter och auktorisationsbidrag till resursservern.
OAuth beskrivs ofta som en valet nyckel för webben.
Nu skulle det verkligen vara uncool att dela dina Facebook- eller Google-uppgifter med någon tredje parts klientprogram som bara behöver veta om dina vänner, eftersom det inte bara ger appen gränslös och oönskad åtkomst till ditt konto, men det har också den inneboende svagheten som är associerad med lösenord. Det är här OAuth kommer till spel, eftersom det beskriver en åtkomstdelegation / behörighetsram som kan användas utan att behöva dela lösenord. Av denna anledning beskrivs OAuth ofta som en valet nyckel för webben. Det kan betraktas som en specialnyckel som tillåter åtkomst till begränsade funktioner och under en begränsad tid utan att ge bort full kontroll, precis som valetknappen för en bil tillåter parkeringsvakt att köra bilen för en kort sträcka, blockerar tillgång till bagageutrymmet och mobiltelefonen ombord.
OAuth är dock inte ett nytt koncept, utan en standardisering och kombinerad visdom av många väl etablerade protokoll. OAuth är inte bara begränsat till sociala medier, utan ger också ett standardiserat sätt att dela information säkert mellan olika typer av applikationer som exponerar deras API till andra applikationer. OAuth 2.0 har en helt ny prosa och är inte bakåtkompatibel med sin föregångare spec. Med detta sagt skulle det vara bra att först täcka några grundläggande OAuth2.0-ordförråd innan du dykar in i ytterligare detaljer.
OAuth 1.0: s största nackdel var den inneboende komplexiteten som behövdes för att implementera specifikationen.
Ingenting egentligen! Twitter fungerar fortfarande bra med OAuth 1.0 och har precis börjat stödja en liten del av 2.0 spec. OAuth 1.0 var en väl genomtänkt specifikation och det var tillåtet att utbyta hemlig information säkert utan att SSL påförde kostnaderna. Anledningen till att vi behövde en uppgradering var mestadels baserat på komplexiteten inför införandet av specifikationen. Nedan följer några områden där OAuth 1.0 inte kunde imponera:
Innan protokollet initieras måste klienten registrera sig hos auktorisationsservern genom att tillhandahålla dess klienttyp, dess omdirigeringsadress (där den vill att auktorisationsservern ska omdirigera till efter att resursägaren ger eller avvisar åtkomsten) och annan information som krävs av servern och i sin tur ges en klientidentifierare (client_id) och klienthemlighet (client_secret). Denna process är känd som kundregistrering. Efter att ha registrerats kan klienten anta ett av följande flöden för att interagera med servern.
OAuth 2.0 ger fem nya flöden till bordet och ger utvecklare flexibiliteten att implementera någon av dem, beroende på vilken typ av kund som är involverad:
Att diskutera varje flöde i detalj skulle vara utanför ramen för denna artikel och jag skulle hellre rekommendera att läsa specifikationen för djup flödesinformation. Men för att få en känsla för vad som händer, låt oss gräva djupare in i ett av de mest använda och stödda flödena: Web Server Flow.
Eftersom detta är ett omriktningsbaserat flöde, måste klienten kunna interagera med resursägarens användaragent (som i de flesta fall är en webbläsare) och är därför vanligtvis lämpad för en webbapplikation. Nedanstående diagram är ett fågelperspektiv av hur slutanvändaren (eller resursägaren) använder klientapplikationen (webbserverbaserad applikation i det här fallet) för att autentisera och auktorisera med behörighetsservern för att få tillgång till de skyddade resurserna av resursservern.
Klienten, på uppdrag av resursägaren, initierar flödet genom att omdirigera till godkännandepunktet med en response_type-parameter som koda, en klientidentifierare, som erhålls under klientregistrering, en omdirigeringsadress, en önskad räckvidd (valfritt) och en lokal stat (om någon). För att få en känsla för hur det verkligen fungerar, här är en skärmdump av hur en typisk förfrågan / svar skulle se ut:
Detta presenterar normalt resursägaren med ett webbgränssnitt där ägaren kan autentisera och kontrollera vilka rättigheter som klientens app kan använda på ägarens vägnar.
Om du antar att resursägaren ger tillgång till klienten omdirigerar auktorisationsservern användaragenten tillbaka till klienten med den omdirigeringsadress som tillhandahållits tidigare tillsammans med godkännandekoden som visas av svaret nedan.
Klienten då inlägg till en annan godkännandepunkt och skickar den behörighetskod som mottogs i det tidigare steget tillsammans med omdirigeringsadressen, dess klientidentifierare och hemliga, erhållna under klientregistreringen och en grant_type-parameter måste ställas in som Behörighetskod.
Servern validerar sedan behörighetskoden och verifierar att omadresseringsadressen är densamma som den var i det tidigare steget. Om det lyckas svarar servern tillbaka med en åtkomsttoken och eventuellt en uppdateringstoken.
Klienten kan nu konsumera API: erna som tillhandahålls av implementeringen och kan fråga resursservern för en begränsad resurs genom att passera åtkomsttoken i auktoriseringsrubriken för begäran. Ett urval av CURL-förfrågan till Googles bloggers API för att få en blogg, med angivande av dess identifierare, skulle se ut så här:
$ curl https://www.googleapis.com/blogger/v3/blogs/5223788876950011016 -H Authorization: OAuth ya29.AHES6ZRTj1GNxAby81Es-p_YPWWNBAFRvBYVsYj2HZJfJHU '
Observera att vi har lagt till åtkomsttoken som en auktoriseringsrubrik i förfrågan och också undvikit token genom att inkludera den i enkla citat, eftersom token kan innehålla specialtecken. Tänk på att flykting åtkomsttoken endast krävs när du använder curl. Det resulterar i att skicka följande förfrågan:
Resursservern verifierar sedan de godkända godkännandena (åtkomsttoken) och, om den lyckas, svarar med den begärda informationen.
Dessa exempel är courtesy of OAuth2.0 Playground och är typiska för hur Google implementerar spec. Skillnader kan observeras när man försöker samma flöde med andra leverantörer (som Facebook eller Salesforce) och det är här där driftskompatibilitetsproblemen kryper in, vilket vi diskuterar lite senare.
Även om det inte är mandat av specen, men vanligtvis är åtkomstbiten kortvariga och kommer med en utgångstid. Så när en åtkomsttoken är utgående skickar klienten uppdateringstecknet till auktorisationsservern tillsammans med dess klientidentifierare och hemlighet, och en grant_type-parameter som refresh_token.
Autorisationsservern svarar sedan med det nya värdet för åtkomsttoken.
Även om en mekanism existerar för att återkalla uppfriskningstoken utfärdat, men normalt lever uppfriskningstoken för alltid och måste skyddas och behandlas som ett hemligt värde.
OAuth 2.0 är definitivt en förbättring jämfört med dess arcane föregångare. Instanser av utvecklingssamhället falter under genomförandet av signaturerna på 1,0 är inte okända. OAuth 2.0 ger också flera nya bidragstyper, som kan användas för att stödja många användningsfall som inbyggda applikationer, men USP av denna spec är dess enkelhet över den tidigare versionen.
Det finns några lösa ändar i specifikationen, eftersom det inte korrekt definierar några nödvändiga komponenter eller lämnar dem upp till implementeringarna för att bestämma, till exempel:
Lösa ändar i OAuth 2.0-specifikationen kommer sannolikt att producera ett brett utbud av icke-driftskompatibla implementeringar.
Det tog IETF om 31 utkastsversioner och avskrivningen av huvudförfattaren / utvecklaren Eran Hammer från utskottet för att slutligen publicera specifikationen. Eran sparkade en kontrovers genom att ringa spec "ett dåligt protokoll och ett fall av död med tusen nedskärningar". Enligt honom var användningen av bärare tokens (sänder tokens över SSL utan att underteckna dem eller någon annan verifikation) över användaren av signaturer (eller MAC-Tokens) som användes i OAuth 1.0 för att signera begäran, ett dåligt drag och ett resultat av fördelning av intressen mellan webben och företagsamhällen.
Specen lämnar säkert många tilläggspunkter i öppen, vilket resulterar i implementeringar som introducerar sina egna parametrar, utöver vad specifikationen redan definierar och ser till att implementeringar från olika leverantörer inte kan interoperera med varandra. Men med OAuths popularitet och adoptionshastighet, med varje stor spelare i staden (Google, Twitter, Facebook, Salesforce, Foursquare, Github etc.) implementerar och anpassar det som passar dem, är OAuth långt ifrån misslyckat . Faktum är att varje webbapplikation som planerar att avslöja sina API: er för andra webbapplikationer måste stödja någon form av autentisering och auktorisering och OAuth passar räkningen här.
Accentsconagua