Přejít k navigační liště

Zdroják » Různé » OAuth – nový protokol pro autentizaci k vašemu API

OAuth – nový protokol pro autentizaci k vašemu API

Články Různé

Proč často u webových aplikací musí uživatelé poskytovat své přihlašovací údaje třetím stranám? V dnešním článku si vysvětlíme, proč je zapotřebí standard pro autentizaci uživatelů. Představíme protokol OAuth, který by mohl zvýšit bezpečnost uživatelských účtů nejen ve Web 2.0 službách a mashupech.

Jaký je problém dnešních webových aplikací?

Dnešní článek začneme připomenutím nedávných událostí. Před několika dny, když se Martin Hassman ptal, zda jsou čeští internetoví odborníci odolní vůči sociálnímu inženýrství, popsal jeden zajímavý problém, který přišel spolu s moderními webovými trendy. S nástupem mashupů (tedy jakýchsi nadstaveb nad webovými službami) se objevila potřeba zajistit mashupu přístup k uživatelským datům na cílové službě. Řada služeb se s tím vyrovnává jednoduše tak, že si od uživatele vyžádá jeho hesla. Popišme si situaci na diskutovaném příkladu.

Jaká je realita?

Nedávno se objevila služba Twitterank, která nabízí jakousi nadstavbu známé služby Twitter. Konkrétní funkce není teď podstatná, důležité je, že k tomu Twitterank potřebuje přístup k vašemu Twitter účtu. Po uživatelích proto požaduje zadání jejich uživatelského jména a hesla na Twitter. To vzbudilo, trochu paradoxně, značnou nevoli u odborné veřejnosti.

Proč paradoxně? Protože to vypadá, že se v tomhle případě projevilo staré přísloví, které říká, že co je dovoleno Jovovi, není dovoleno volovi. Přihlašovací data k lecjakým účtům po nás totiž dnes požaduje kdekdo – od Google přes Facebook až po naprosto obskurní služby, které vám tvrdí, že potřebují vaše jméno a heslo na GMail, např. aby vám umožnily lepší prožitek z používání. Ve srovnání s tím, co po vás chtějí jiné služby, je přístup k Twitter účtu nedůležitá banalita. Jinde chtějí přímo údaje k e-mailu nebo FTP přístup k serveru (svého času to požadoval Blogger při generování blogů via FTP). A jaké možnosti má dnes uživatel? Buď své údaje předá a bude věřit, že je prostředník nezneužije, nebo službu nebude používat.

Každopádně i sebedůvěryhod­nější služba znamená určité riziko kompromitace vašeho účtu. Smutnou realitou je, že to zatím většina služeb, snad v euforii z netušených Web 2.0 možností, moc neřeší a minimálně do doby prvního velkého průšvihu ani řešit nebude. Zatím se účty neztrácejí a uživatelé sdělují třetím stranám své údaje jako by se nechumelilo… Krom toho jde tento přístup proti všem bezpečnostním poučkám a pravidlům a staví tak na hlavu všechny rady pro bezpečné užívání internetu.

Jak bychom mohli problém obejít?

Metod, jak obejít nutnost svěřit prostředníkovi (mashupu, službě apod.) své přihlašovací údaje k jiné službě, je víc. Na jedné straně jsou tradiční, defenzivní metody, jako je například možnost zvolit si u služby jakési sekundární heslo pouze pro přístup k některým datům či API (takže případné zneužití údajů nemá tak fatální následky) či generování API klíčů, které jsou pak posílány místo plných hesel.

Na druhé straně pak existují více či méně sofistikované postupy, které prostředníka odstíní od hesla rafinovaněji. Třeba pomocí nějakých „kejklů a fíglů“, např. jak nedávno popsal David Grudl:

K prostředníkovi se odešlou všechna potřebná data vyjma hesla. To neopustí klientův počítač, ale bude zapsáno ve fragmentu URI (tedy za znakem #, tato část adresy se totiž při HTTP komunikaci na server neposílá). Server udělá potřebné operace a pro závěrečnou komunikaci se serverem služby vygeneruje JavaScript. Ten postaví přes DOM formulář, heslo si vezme z window.location.hash  a odešle jej. Poté zpracuje výsledek a předá uživateli (nebo znovu prostředníkovu serveru pro finální zpracování). Podstatné je, jak jsem psal, že heslo neopustí klientův počítač.

Můžeme také použít nezávislého správce identit po vzoru OpenID.

Jaké je správné řešení?

Představte si nyní univerzální způsob, jak povolit Twitteranku přístup k údajům na Twitteru, aniž by mu uživatel musel prozradit svoje heslo do Twitteru. Fungovalo by to takto: Uživatel přijde na stránky Twitteranku. Nezadává přístupové údaje k účtu, ale pouze klikne na tlačítko „Přihlásit k Twitter účtu“. Je přesměrován na stránky Twitteru, kde se normálně přihlásí svým jménem a heslem. V nějakém formuláři pak potvrdí, že Twitterank smí přistupovat k jeho Twitter účtu, zadá např. k jakým datům smí Twitterank přistupovat a jak dlouho, a po potvrzení je přesměrován zpět na Twitterank. Zároveň je předán klíč, s nímž se Twitterank může připojit na Twitter API a vyžádat si potřebné údaje. Klíč je vystaven pro konkrétní službu a konkrétní použití na určitou dobu; riziko jeho zneužití je tak minimalizováno a (co je nejdůležitější) citlivé přihlašovací údaje tak putují jen mezi uživatelem a cílovou službou.

Na pozadí probíhají snadno představitelné operace: Twitterank požádá nejprve Twitter o jednorázový token. Pak přesměruje HTTP redirektem uživatele na Twitterovskou přihlašovací bránu a v požadavku předá tento token. Twitter udělá, co je potřeba, a po potvrzení přesměruje uživatele opět redirektem zpět na Twitterank. Ten požádá Twitter o přístupový klíč k danému tokenu a s tímto klíčem pak přistupuje k API.

Protokol OAuth

Představili jste si to? Pokud ano, tak v tuhle chvíli už víte, jak funguje OAuth autentizace.

Schema průběhu autentizace pomocí OAuth

Obrázek pochází ze specifikace OAuth.

OAuth je protokol, navržený pro, cituji: bezpečnou API autentizaci jednoduchým a jednotným způsobem pro webové i desktopové aplikace. Jeho specifikace popisuje podrobně fungování oné výše popsané výměny tokenů a klíčů; nijak nedefinuje vlastní komunikaci s webovou aplikací ani není vázané na konkrétní typ API (pouze je omezeno na HTTP protokol). OAuth lze tedy použít jako metodu ověření uživatele k jakémukoli typu API (SOAP, XML-RPC, REST atd.), a to nejen na webových aplikacích.

Závěr

OAuth je poměrně nový protokol, který se začíná zvolna šířit – ze služeb známých v České republice ho nabízí třeba Pownce či Google. OAuth funkce přitom není nijak složitá a k dispozici jsou knihovny pro hlavní programovací jazyky, takže nasazení nevyžaduje žádné obrovské investice ani studium tlustých knih – stačí, když použijete hotovou knihovnu.

Do běžícího systému lze OAuth implementovat během několika hodin. Pokud provozujete nějakou službu a nabízíte k ní API, zkuste se zamyslet, zda by OAuth nebyla vhodná autentizační metoda a zda by se vám (a vašim uživatelům) její zavedení nevyplatilo.

Svěřujete svá hesla neznámým aplikacím?

Komentáře

Subscribe
Upozornit na
guest
14 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Rado2

Nie je mi celkom jasne naco to vlastne je.
Je to preto, aby v databaze na serveri nejakej sluzby neboli moje prihlasovacie mena?
Bude tam "len" nejaky kluc ktorym sa bude sluzba autorizovat?
Ked niekto hackne ten server tak nemoze ten kluc pouzit?
Ked ta sluzba bude chciet zneuzit moj account, nestaci jej na to ten kluc?

Anonymní

Samotnému OAuth je věnován asi jeden odstavec se stručným co to je a ještě stručnějším jak to funguje. Podrobnější popis by nebyl? Proč používat tohle a ne něco vlastního? Jde snad o první z mnoha článků o OAuth?

Martin Hassman

Proč používat tohle a ne něco vlastního?

V tom je význam standardů. Pokud všichni podporují jeden mechanismus, tak spolu můžou všichni snadno komunikovat. Vlastní řešení je určitě možné, ale pak musíte přesvědčit druhou stranu, aby je také implementovala. Oč je pak snazší použít hotovou knihovnu pro OAuth navíc, když druhá strana možná už dávno udělala totéž.

Anonymní

Jop, zájem by byl.

Anonymní

Jěště takto, nejlepší by bylo to ukázat na konkrétním případě implementace.

shMoula

Takhle funguje napr overeni nove aplikace pro flickr (kFlickr) a mam dojem, ze takto se autorizuji i externi aplikace na facebooku.

dc

Dve veci. Jenak mashup je uz fakt trosicka moc.Az tak by ste jazyk prznit nemuseli,aj ked je to Vasa cestina.
A druha vec, cim dalej tym je mi viac zle z celeho web developmentu a smeru ktorym sa to ubera.Prestavam pomalicky chapat,a sam mam chut sa otocit celemu tomuto smeru chrbtom, preco sa jednoduche veci stale robia zlozitejsie a zlozitejsie.Preco sa silou mocou snazime znasilnovat protokol a vobec cely web k tomu aby fungoval ako bezne desktopove aplikacie ked tie tu uz davno su.Ked si zratam vsetky aktualne technologie a postupy ktore sa pouzivaju pri webe tak uz zdaleka to neni nejaky rapid development, a zacinaju nevyhody prevazovat nad vyhodami.Bohuzial ani na desktope to neni o moc lepsie (.NET a java urobili svoje).

Anonymní

ale vubec, v tomto pripade (stejne tak jako ku prikladu v pripade REST) se nejedna o zadne "ohybani protokolu"

naopak (a jde to pekne videt treba prave na RESTu), protokol se vyuziva plne (nejenom metody GET a POST), a tak, jak byl puvodne zamyslen. V pripade OAuth jde jen o to, ze autentikaci (authentication) provede sam uzivatel, jehoz si sluzby mezi sebou presmerovavaji (header('Location: …'), a prenasen je pouze jednoduchy 'token', jehoz 'schopnosti' jsou navic omezeny jak v case, tak co se funkcnosti tyce. Tedy pokud jsem to pochopil spravne

Ivan Novakov

Kdo to chce delat poradne, pouzije SAML :).

http://shibboleth.internet2.edu/

Martin

Jak se to liší od OpenID? Proč místo OAuth nepoužít OpenID? Zajímavá autentizace je přes dongl Yubico.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.