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.

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.