| OAuth | |
|---|---|
| název | OAuth |
| Mediální soubory na Wikimedia Commons | |
OAuth je otevřený autorizační protokol (schéma) , který poskytuje třetí straně omezený přístup k chráněným zdrojům uživatele, aniž by jí (třetí straně) přenášel přihlašovací jméno a heslo [1] [2] .
Práce na protokolu byly zahájeny v listopadu 2006 a poslední verze OAuth 1.0 byla schválena 4. prosince 2007. Jako následný vývoj se v roce 2010 objevil protokol OAuth 2.0, jehož poslední verze byla publikována v říjnu 2012 jako RFC 6749 .
Jedním z problémů autentizace a bezpečnosti informací je, že uživatelé obvykle používají několik různých služeb (například na Google, Twitter, Apple atd.), a tedy několik účtů s vlastními přihlašovacími údaji a hesly. Uživatelé tedy potřebují uchovávat a chránit mnoho přihlašovacích údajů a hesel. Vzhledem k tomu, že každá ze služeb má svůj vlastní bezpečnostní systém s vlastními zranitelnostmi a nedostatky, je toto vše na úkor pohodlí a bezpečnosti uživatelů. Pokud například uživatelé používají stejná hesla pro různé služby, pak se po získání přístupu k jednomu z účtů útočníkům značně zjednoduší postup hackování dalších účtů [3] .
Dvoufázové ověření (například Google Authenticator ) lze použít ke zvýšení bezpečnosti, když je pro potvrzení použita jiná uživatelská služba (například když je pro ověření na webu vyžadován kód zaslaný na mobilní telefon ). S tímto přístupem se výrazně snižuje pravděpodobnost hacknutí. Klíčovou vlastností používání OAuth je, že pokud má uživatel dobře zabezpečený účet, tak se pomocí něj a technologie OAuth může autentizovat k dalším službám, přičemž uživatel nemusí prozradit své hlavní heslo. Například uživatel, který chce poskytnout online službě pro tisk fotografií přístup k fotografiím ze svého účtu na Facebooku , nemusí službě poskytovat heslo k tomuto účtu. Místo toho předá autorizaci Facebooku, který (se svolením uživatele nebo správce služby) již poskytuje online tiskové službě požadovaný přístup k fotografiím [3] .
OAuth se objevil v listopadu 2006 během vývoje protokolu OpenID pro mikroblogovací službu Twitter Blaine Cookem . Spolu s Chrisem Messinou hledal způsob , jak pomocí OpenID poskytnout přístup k Twitter API , aniž by službě udával heslo. Ve spolupráci se spolutvůrcem OpenID Davidem Recordonem analyzovali funkčnost OpenID a také proprietární autorizační protokoly, jako jsou Flickr Auth , Google AuthSub a Yahoo! BBAuth , načež došli k závěru, že je potřeba nový otevřený protokol [4] .
V dubnu 2007 byla vytvořena skupina inženýrů, kteří pracovali na jeho vytvoření. Na jeho práci se podíleli zaměstnanci společností Google a AOL (která zároveň zavedla svůj vlastní protokol OpenAuth ). Finální verze jádra protokolu OAuth 1.0 byla vydána 4. prosince 2007. V roce 2008 probíhaly práce na standardizaci protokolu v Internet Engineering Council [4] .
Dne 15. dubna 2009 nabídl Twitter svým uživatelům řešení, které umožňuje webům a službám třetích stran přístup k jejich účtům. Jmenoval se „Přihlásit se pomocí Twitteru“ a byl založen na protokolu OAuth. Tato událost spustila první rozsáhlou studii zranitelnosti protokolu a o několik dní později byla objevena potenciální zranitelnost ovlivňující všechny existující implementace OAuth. Poté, 23. dubna, byl vývojářskou komunitou vydán první bezpečnostní doplněk protokolu, který byl zahrnut do aktualizované specifikace OAuth Core 1.0 Revize A zveřejněné 24. června. V dubnu 2010 byla vydána bílá kniha RFC 5849 o standardu OAuth [4] .
V roce 2010 byly zahájeny práce na nové verzi protokolu OAuth 2.0, která nebyla zpětně kompatibilní s OAuth 1.0 [1] . V říjnu 2012 byl rámec pro OAuth 2.0 publikován v RFC 6749 a použití nosiče tokenů v RFC 6750 .
Pro vytvoření OAuth 2.0 bylo několik předpokladů. Za prvé, OAuth je poměrně netriviální pro použití na straně klienta. Jedním z cílů při vývoji nového OAuth je usnadnit vývoj klientských aplikací. Za druhé, navzdory implementaci tří metod (nazývaných toky) deklarovaných ve standardu pro získání tokenu ( jedinečného identifikátoru) pro autorizaci: pro webové aplikace, desktopové klienty a mobilní klienty jsou ve skutečnosti všechny tři metody sloučeny do jedné. A za třetí, protokol se ukázal jako špatně škálovatelný. Kromě nových streamů do něj byly přidány [5] [6] :
V tuto chvíli OAuth 2.0 využívá velké množství služeb, jako je Google , Instagram , Facebook , VKontakte a další.
V červenci 2012 Eran Hammer, současný editor standardu OAuth 2.0, oznámil svou rezignaci po třech letech práce na novém standardu a požádal o odstranění jeho jména ze specifikací. O svých názorech hovořil na svých webových stránkách [7] a později přednesl přednášku [8] . David Recordon také později vyškrtl své jméno ze specifikace bez udání důvodů [ 9] . Dick Hardt se stal editorem standardu OAuth2.0 a navzdory názorům Erana Hammera byl rámec OAuth 2.0 publikován v RFC 6749 v říjnu 2012 [1] .
Při použití autorizace OAuth uživatel nepřenáší své přihlašovací jméno a heslo k chráněným zdrojům přímo do aplikace [3] . Proto:
V případě autorizace bez použití protokolu OAuth musí uživatel zaslat své přihlašovací jméno a heslo. Tato metoda má další nevýhody [3] :
Ačkoli OAuth a OpenID mají mnoho společného, OAuth je protokol sám o sobě a nemá nic společného s OpenID [10] :
Základní pojmy používané v protokolech a příklady jejich použití.
OAuth 1.0 definuje tři role: klient, server a vlastník zdroje. Tyto tři role jsou přítomny v jakékoli operaci OAuth, v některých případech je klient také vlastníkem prostředku. Původní verze specifikace používá pro tyto role jinou sadu termínů: spotřebitel (klient), služba (server) a uživatel (vlastník zdroje) [11] . V protokolu OAuth 2.0 došlo k oddělení rolí serveru: autorizační server a server, který uchovává chráněné zdroje, jsou přiděleny samostatně [6] .
OAuth podporuje 3 metody podpisu používané k podepisování a ověřování požadavků: PLAINTEXT , HMAC - SHA1 a RSA - SHA1 . Použití PLAINTEXTu je triviální a jeho výpočet zabere podstatně méně času, ale může být zabezpečen pouze přes HTTPS nebo podobné zabezpečené kanály. HMAC - SHA1 nabízí jednoduchý a obecný algoritmus, který je dostupný na většině platforem, ale ne na všech starších zařízeních, a používá symetrický sdílený klíč. RSA - SHA1 poskytuje vylepšené zabezpečení pomocí páru klíčů, ale je složitější a vyžaduje generování klíčů [12] .
Aby se zabránilo hrozbě opětovného použití požadavku, používá protokol OAuth označení nonce a časové razítko . Termín "nonce" se používá k označení jednorázového kódu, což je náhodná sada písmen a čísel a je navržen tak, aby jednoznačně identifikoval požadavek. Jedinečný identifikátor v požadavku umožňuje poskytovateli služby zabránit jeho opětovnému použití. Tento přístup je implementován generováním jedinečného řetězce pro každý požadavek odeslaný na server klientem. Aby se zabránilo opětovnému použití požadavků, server MUSÍ ukládat přijaté nonce [12] .
Ukládání všech přijatých nonces však může být pro server velmi nákladné. Aby se zabránilo nadměrné režii úložiště v OAuth, je ke každému požadavku přidáno časové razítko, které serveru umožňuje ukládat nonce pouze po určenou omezenou dobu. Po obdržení požadavku se štítkem dříve, než je povoleno, jej server odmítne [12] .
OAuth 1.0 a OAuth 2.0 používají tři typy oprávnění: přihlašovací údaje klienta ( spotřebitelský klíč a tajné nebo klientské přihlašovací údaje ) , dočasné přihlašovací údaje ( token požadavku a tajné nebo dočasné přihlašovací údaje ) a tokeny ( přístupový token a tajné nebo anglické přihlašovací údaje ) [13] [ 3] .
Přihlašovací údaje klienta se používají k ověření klienta. Server může klientům poskytovat speciální služby, jako je omezení volného přístupu nebo poskytování podrobnějších informací vlastníkovi zdroje o klientech, kteří se pokoušejí přistupovat k chráněným zdrojům. V některých případech nejsou přihlašovací údaje klienta zabezpečené a lze je použít pouze pro informační účely, například v aplikacích pro stolní počítače.
Token se používá místo jména a hesla vlastníka zdroje. Vlastník zdroje nezveřejňuje své přihlašovací údaje klientovi, ale umožňuje serveru vydat klientovi token – speciální třídu přihlašovacích údajů, která klientovi poskytuje určité omezené možnosti. Klient používá token pro přístup k chráněnému zdroji, aniž by znal heslo vlastníka zdroje. Token se skládá z digitálního podpisu, obvykle (ale ne vždy) náhodné sady písmen a čísel, která je jedinečná a kryptograficky silná, a klíče k ochraně tokenu před neoprávněným použitím. Token je omezený z hlediska oprávnění a trvání a může být vlastníkem zdroje kdykoli odvolán, aniž by to ovlivnilo tokeny vydávané jiným klientům [13] .
Proces autorizace OAuth také používá sadu dočasných pověření, která se používají během fáze žádosti o autorizaci. Aby bylo možné uspokojit různé druhy klientů (webové rozhraní, desktop, mobilní zařízení atd.), dočasná oprávnění nabízejí další flexibilitu a zabezpečení [13] .
Vysvětlíme si, jak funguje protokol OAuth 1.0 na příkladu [13] . Předpokládejme, že uživatel (vlastník zdroje) chce vytisknout své fotografie (zdroje) nahrané na photos.example.net (server) pomocí tiskové služby "printer.example.net" (klient).
Protokol OAuth 2.0 není zpětně kompatibilní s protokolem OAuth 1.0 [1] . Spíše než doplnit OAuth 1.0 bylo rozhodnuto vyvinout jiný protokol [10] . Proto je způsob, jakým OAuth 1.0 a OAuth 2.0 fungují, odlišný. Ve standardu OAuth 2.0 jsou tedy popsány následující toky (scénáře interakce stran) [1] :
OAuth podporuje dvě metody ověřování zpráv od klienta: HMAC - SHA1 a RSA - SHA1 . Je možné posílat zprávy bez podpisu, pak je v poli typu podpisu uvedeno „ prostý text “. V tomto případě ale podle specifikace musí být spojení mezi klientem a serverem navázáno přes protokol SSL nebo TLS [13] .
| Protokoly ověřování a výměny klíčů | |
|---|---|
| Se symetrickými algoritmy | |
| Se symetrickými a asymetrickými algoritmy | |
| Protokoly a služby používané na internetu | |