| OAuth | |
|---|---|
| namn | OAuth |
| Mediafiler på Wikimedia Commons | |
OAuth är ett öppet auktoriseringsprotokoll (schema) som ger en tredje part begränsad tillgång till användarens skyddade resurser utan att överföra inloggning och lösenord till den (tredje parten) [1] [2] .
Arbetet med protokollet började i november 2006 och den senaste versionen av OAuth 1.0 godkändes den 4 december 2007. Som en efterföljande utveckling dök OAuth 2.0-protokollet upp 2010, vars senaste version publicerades i oktober 2012 som RFC 6749 .
Ett av problemen med autentisering och informationssäkerhet är att användare vanligtvis använder flera olika tjänster (till exempel på Google, Twitter, Apple , etc.), och följaktligen flera konton med egna inloggningar och lösenord. Därför måste användare lagra och skydda många inloggningar och lösenord. Eftersom var och en av tjänsterna har sitt eget säkerhetssystem med sina egna sårbarheter och brister, är allt detta skadligt för användarnas bekvämlighet och säkerhet. Till exempel, om användare använder samma lösenord för olika tjänster, efter att ha fått tillgång till ett av kontona, förenklas hackningsproceduren för andra konton för angripare avsevärt [3] .
Tvåstegsautentisering (till exempel Google Authenticator ) kan användas för att öka säkerheten, när en annan användartjänst används för bekräftelse (till exempel när en kod som skickas till en mobiltelefon krävs för autentisering på en webbplats ). Med detta tillvägagångssätt minskar sannolikheten för hackning avsevärt. Nyckelfunktionen med att använda OAuth är att om användaren har ett välskyddat konto kan han med hjälp av det och OAuth-teknik autentisera sig till andra tjänster, samtidigt som användaren inte behöver avslöja sitt huvudlösenord. En användare som till exempel vill ge en fotoutskriftstjänst online tillgång till foton från sitt Facebook-konto behöver inte förse tjänsten med lösenordet för det kontot. Istället skickar den auktorisering till Facebook, som (med tillstånd från användaren eller tjänsteadministratören) redan förser onlineutskriftstjänsten med nödvändig tillgång till foton [3] .
OAuth dök upp i november 2006, under utvecklingen av OpenID- protokollet för Twitters mikrobloggtjänst av Blaine Cook . Tillsammans med Chris Messina letade han efter ett sätt att använda OpenID för att ge tillgång till Twitter API utan att ge tjänsten ett lösenord. I samarbete med OpenID-medskaparen David Recordon analyserade de funktionaliteten hos OpenID såväl som proprietära auktoriseringsprotokoll som Flickr Auth , Google AuthSub och Yahoo! BBAuth , varefter de kom fram till att det finns ett behov av ett nytt öppet protokoll [4] .
I april 2007 bildades en grupp ingenjörer för att arbeta med dess skapelse. Anställda på Google och AOL (som samtidigt införde sitt eget OpenAuth- protokoll ) deltog i dess arbete. Den slutliga versionen av OAuth 1.0-protokollkärnan släpptes den 4 december 2007. Under 2008 pågick ett arbete med att standardisera protokollet i Internet Engineering Council [4] .
Den 15 april 2009 erbjöd Twitter sina användare en lösning som gör det möjligt för tredje parts webbplatser och tjänster att komma åt sina konton. Den hette "Logga in med Twitter" och baserades på OAuth. Denna händelse utlöste protokollets första omfattande sårbarhetsstudie, och några dagar senare upptäcktes en potentiell sårbarhet som påverkar alla befintliga OAuth-implementeringar. Efter det, den 23 april, släpptes det första säkerhetstillägget till protokollet av utvecklargemenskapen, vilket inkluderades i den uppdaterade OAuth Core 1.0 Revision A-specifikationen, publicerad den 24 juni. I april 2010 släpptes vitboken RFC 5849 om OAuth-standarden [4] .
Under 2010 började arbetet med en ny version av OAuth 2.0-protokollet som inte var bakåtkompatibelt med OAuth 1.0 [1] . I oktober 2012 publicerades ramverket för OAuth 2.0 i RFC 6749 och användningen av tokenbärare i RFC 6750 .
Det fanns flera förutsättningar för att skapa OAuth 2.0. Först och främst är OAuth ganska otrivialt att använda på klientsidan. Ett av målen med att utveckla nya OAuth är att göra det lättare att utveckla klientapplikationer. För det andra, trots implementeringen av tre metoder (kallade flöden) som deklareras i standarden för att erhålla en token (unik identifierare) för auktorisering: för webbapplikationer, stationära klienter och mobila klienter, i själva verket slås alla tre metoderna samman till en. Och för det tredje visade sig protokollet vara dåligt skalbart. Förutom nya strömmar lades [5] [6] till :
För närvarande används OAuth 2.0 av ett stort antal tjänster, såsom Google , Instagram , Facebook , VKontakte och andra.
I juli 2012 meddelade Eran Hammer, den nuvarande redaktören för OAuth 2.0-standarden, sin avgång efter tre års arbete med den nya standarden och begärde att hans namn skulle tas bort från specifikationerna. Han talade om sina åsikter på sin hemsida [7] och höll senare ett föredrag [8] . David Recordon tog också senare bort sitt namn från specen utan att ange skäl [ 9] . Dick Hardt blev redaktör för OAuth2.0-standarden, och trots synpunkter från Eran Hammer publicerades OAuth 2.0-ramverket i RFC 6749 i oktober 2012 [1] .
Vid användning av OAuth- auktorisering överför användaren inte sin inloggning och lösenord till skyddade resurser direkt till applikationen [3] . Det är därför:
Vid auktorisering utan att använda OAuth-protokollet måste användaren skicka inloggning och lösenord. Denna metod har ytterligare nackdelar [3] :
Även om OAuth och OpenID har mycket gemensamt, är OAuth ett protokoll i sig och har ingenting att göra med OpenID [10] :
Grundläggande begrepp som används i protokoll och exempel på deras användning.
OAuth 1.0 definierar tre roller: klient, server och resursägare. Dessa tre roller finns i alla OAuth-operationer, i vissa fall är klienten också ägare till resursen. Den ursprungliga versionen av specifikationen använder en annan uppsättning termer för dessa roller: konsument (klient), tjänst (server) och användare (resursägare) [11] . I OAuth 2.0-protokollet fanns det en separation av serverroller: en auktoriseringsserver och en server som lagrar skyddade resurser tilldelas separat [6] .
OAuth stöder 3 signaturmetoder som används för att signera och validera förfrågningar: PLAINTEXT , HMAC - SHA1 och RSA - SHA1 . PLAINTEXT är trivialt att använda och tar betydligt mindre tid att beräkna, men det kan bara vara säkert över HTTPS eller liknande säkra kanaler. HMAC - SHA1 erbjuder en enkel och generisk algoritm som är tillgänglig på de flesta plattformar, men inte alla äldre enheter, och använder en symmetrisk delad nyckel. RSA - SHA1 ger förbättrad säkerhet med ett nyckelpar, men är mer komplex och kräver nyckelgenerering [12] .
För att förhindra hotet om återanvändning av begäran använder OAuth en nonce och en tidsstämpel . Termen "nonce" används för att hänvisa till en engångskod, som är en slumpmässig uppsättning bokstäver och siffror och är utformad för att unikt identifiera en begäran. Genom att ha en unik identifierare i en begäran kan tjänsteleverantören förhindra att den återanvänds. Detta tillvägagångssätt implementeras genom att generera en unik sträng för varje begäran som skickas till servern av klienten. För att förhindra återanvändning av förfrågningar MÅSTE servern lagra mottagna aviseringar [12] .
Men att lagra alla mottagna nonces kan vara mycket kostsamt för servern. För att förhindra överdriven lagringskostnader i OAuth läggs en tidsstämpel till varje begäran, vilket gör att servern endast kan lagra nonce under en viss begränsad tid. Vid mottagande av en begäran med en etikett tidigare än tillåtet, avvisar servern den [12] .
OAuth 1.0 och OAuth 2.0 använder tre typer av auktoritet: klientuppgifter ( konsumentnyckel och hemlig eller klientuppgifter ) , tillfälliga autentiseringsuppgifter ( begäran token och hemliga eller tillfälliga autentiseringsuppgifter ) och tokens ( åtkomsttoken och hemlig eller engelsk token ) [13] [ 3] .
Klientens autentiseringsuppgifter används för att autentisera klienten. Servern kan tillhandahålla speciella tjänster till klienter, såsom att strypa fri åtkomst eller ge resursägaren mer detaljerad information om klienter som försöker komma åt skyddade resurser. I vissa fall är klientuppgifterna inte säkra och kan endast användas i informationssyfte, till exempel i skrivbordsprogram.
Token används istället för resursägarens namn och lösenord. Resursägaren avslöjar inte sina autentiseringsuppgifter för klienten, utan tillåter servern att utfärda en token till klienten - en speciell klass av autentiseringsuppgifter som ger klienten vissa begränsade möjligheter. Klienten använder token för att komma åt en skyddad resurs utan att känna till resursägarens lösenord. Token består av en digital signatur, vanligtvis (men inte alltid) en slumpmässig uppsättning bokstäver och siffror som är unik och kryptografiskt stark, och en nyckel för att skydda token från obehörig användning. Tokenet är begränsat vad gäller auktoritet och varaktighet och kan återkallas när som helst av ägaren av resursen, utan att det påverkar tokens som utfärdats till andra klienter [13] .
OAuth-auktoriseringsprocessen använder också en uppsättning tillfälliga autentiseringsuppgifter som används under auktoriseringsbegäran. För att tillgodose olika typer av klienter (webbgränssnitt, stationära datorer, mobiler, etc.), erbjuder tillfälliga behörigheter ytterligare flexibilitet och säkerhet [13] .
Låt oss förklara hur OAuth 1.0-protokollet fungerar med ett exempel [13] . Anta att en användare (resursägare) vill skriva ut sina foton (resurser) uppladdade till photos.example.net (server) med hjälp av utskriftstjänsten "printer.example.net" (klient).
OAuth 2.0-protokollet är inte bakåtkompatibelt med OAuth 1.0-protokollet [1] . Istället för att komplettera OAuth 1.0 togs beslutet att utveckla ett annat protokoll [10] . Därför är sättet OAuth 1.0 och OAuth 2.0 fungerar annorlunda. Så i OAuth 2.0-standarden beskrivs följande flöden (scenarier för interaktion mellan parterna) [1] :
OAuth stöder två metoder för autentisering av meddelanden från klienten: HMAC - SHA1 och RSA - SHA1 . Det är möjligt att skicka meddelanden utan en signatur, då indikeras " ren text " i signaturtypfältet. Men i det här fallet, enligt specifikationen, måste anslutningen mellan klienten och servern upprättas via SSL- eller TLS-protokollet [13] .
| Autentisering och nyckelutbytesprotokoll | |
|---|---|
| Med symmetriska algoritmer | |
| Med symmetriska och asymmetriska algoritmer | |
| Protokoll och tjänster som används på Internet | |