Jednou z oblastí, s nimiž se setká na internetu snad každý, ať už jako vývojář nebo jako uživatel, je uživatelská autentizace, tedy způsob, jakým uživatel prokáže serveru – či obecně poskytovateli nějaké služby – svou identitu. Možná by se mohlo zdát, že zde není moc co vymýšlet, když koncept „jméno + heslo“ přece funguje univerzálně. V následujících řádcích se vás pokusím přesvědčit o opaku.

Jak autentizace probíhá dnes

Autentizace uživatele vypadá v 99 % případů takto: Uživatel požádá o přístup k nějaké službě. Služba jej vyzve, aby se identifikoval. Uživatel zadá (do nějakého formuláře či jiným způsobem) svůj jednoznačný identifikátor (uživatelské jméno) a jako potvrzení, že se tímto jménem prokazuje oprávněně, přidá smluvenou informaci, která by měla být známa jen jemu a poskytovateli služby (heslo). Služba si údaje ověří a na základě srovnání se svými záznamy rozhodne o tom, zda uživateli povolí přístup.

Klasický web, a tedy naprostá většina v současnosti fungujících služeb, tento přístup implementuje nejjednodušším možným způsobem, a to tak, že si udržují vlastní databázi uživatelských účtů. Uživatel se před prvním přístupem ke službě musí zaregistrovat. Během registrace je mu vytvořen účet a je dohodnuto jméno a heslo. Tento proces znají snad všichni uživatelé internetu, a velká část internetových vývojářů jistě někdy stála před úkolem navrhnout či vytvořit správu uživatelských účtů.

Výhody tohoto přístupu jsou zřejmé: Správa uživatelských účtů může být přizpůsobena do posledního detailu potřebám konkrétní služby, služba má nad svými uživateli naprostou kontrolu a celý mechanismus je, při dobrém návrhu, relativně odolný proti kompromitaci. Z hlediska provozovatele je takový přístup téměř ideální.

Nevýhody a omezení klasického řešení

Pro uživatele ale má tento přístup i některé nezanedbatelné nevýhody. Asi nejviditelnější je, že člověk, který využívá víc služeb, se za čas ztratí v záplavě různých jmen a hesel. Pamatovat si, kde jsem „maly“, kde „mmaly“, kde „martinm“ a kde „martin.maly“ (nebo snad „martinmaly“?) je nad lidské síly. Nastupují proto všelijaké pomůcky, které si tyto údaje pamatují za vás, nebo vám rovnou ke každé službě a jménu vygenerují i silné heslo… Pokud ale chceme ke službám přistupovat z různých počítačů, je potřeba nějak tyto pomůcky synchronizovat, což přináší další komplikace.

Další nevýhodou je nepřenositelnost identity a její nejednoznačnost. Tato nevýhoda je například u mailových schránek naprosto zanedbatelná, ale jakmile vstoupíme do světa Web2.0, kde uživatelé vytvářejí obsah (třeba diskusní fóra či komentáře), tak se může projevit. Uživatelská identita (uživatelské jméno) je totiž unikátní jen v rámci jedné služby nebo rodiny služeb – jako příklad si můžeme uvést „Seznam mail“, který lze použít na všech službách z „rodiny Seznamu“. Na jiném serveru může v diskusi pod stejným jménem vystupovat někdo jiný (a vice versa – ten samý člověk bude mít na jiném serveru jiné uživatelské jméno).

Hledá se lepší řešení

A právě s větším rozmachem uživatelsky vytvářeného obsahu se tyto nevýhody klasického přístupu ukázaly jako natolik nepříjemné, že bylo načase hledat nějaký alternativní postup.

Zde dovolte malou osobní odbočku: V roce 2003 jsme po spuštění Bloguje.cz s dalšími blogery přemýšleli nad tím, jak jednoznačně identifikovat komentátory na různých blozích. Stávalo se totiž, že člověk dostal neprávem vynadáno za to, jaké nesmysly píše tam či onde – a ve skutečnosti to byl někdo jiný, kdo si, buď nevědomky nebo záměrně, zvolil stejnou přezdívku. Nebo na různých blozích psali dva různí komentátoři pod stejnou přezdívkou, což bylo matoucí. Hledali jsme tedy způsob, který by šlo snadno implementovat, který by umožnil komentátorům vystupovat na různých blozích pod stejnou přezdívkou a zároveň zabraňoval tomu, aby pod stejnou přezdívkou vystupoval někdo jiný. Nakonec jsme se shodli na tom, že řešení spočívá v nějakém nezávislém správci, který by ověřoval identity jednotlivých komentátorů (pokud by o to měli zájem, samo sebou). Myšlenka pěkná, ale přišla příliš brzo a nebyla síla (ani vůle) ji prosadit.

Nezávislá autentizační autorita

Myšlenka nezávislé autority, která by spravovala uživatelské identity, byla logickým vyústěním úvah nad tím, jak udělat autentizaci tak, aby uživatelská identita byla univerzální, jednotná, unikátní a nezávislá. Univerzální, tedy nikoli omezená na jednu službu či rodinu služeb, ale použitelná pro jakoukoli webovou (a nejen webovou) službu. Jednotná, tedy pro všechny služby stejná, a zároveň unikátní, tedy aby se s ní nemohl prokazovat nikdo jiný než oprávněný uživatel. A konečně nezávislá, ať už si pod tímto slovem představíme „bezplatná“, „otevřená“, „nepropojená s poskytovatelem služby“ nebo „bez licenčních poplatků“.

Správa identit třetí stranou („providerem“) přináší některé zásadní výhody: Uživatel nepotřebuje heslo ke každé službě, stačí mu znát jen heslo k účtu u správce identity. S touto identitou se pak přihlašuje na různé služby. Taková identita pak jednoznačně identifikuje konkrétního člověka, a to i na různých službách. Provozovatel služby se pak nemusí starat o autentizaci a všechny problémy s ní spojené (zabezpečený přenos údajů, obnova zapomenutých hesel, zabezpečení přihlašovacích dat), pouze implementuje komunikaci s autentifikační autoritou.

Samo sebou, ruku v ruce jdou nevýhody. Pro uživatele nejzásadnější nevýhodou je „efekt kroužku na klíče“ – pokud je jeho identita kompromitována (prozrazení hesla apod.), tak je kompromitována na všech službách, kam se s touto identitou přihlašuje. Provozovatelé zase ztrácí část kontroly nad informacemi o uživatelích – v tom nejextrémnějším případě dostanou pouze jakýsi číselný identifikátor, z něhož nelze o uživateli zjistit nic. Ono to v zásadě nevadí, ale někteří provozovatelé takovou ztrátu mohou nést těžce.

V posledních třech letech bylo navrženo několik univerzálních metod, které implementují tento přístup. Nejznámějšími představiteli jsou OpenID a LiveID, ale existují i další.

Pokračování příště

V tomto úvodním seznámení jsme se věnovali obecně distribuovaným autentizačním metodám, jejich smyslu a účelu, pro které byly navrženy. V dalších dílech si představíme jednotlivé metody podrobněji a nakonec si ukážeme i praktický příklad implementace takové metody.