Autentizační protokol OpenID Connect, který mohou již dva roky používat poskytovatelé služeb implementující přihlášení přes mojeID, přináší nejen celkové zjednodušení implementace, ale také vyšší úroveň zabezpečení. Starší protokol OpenID 2.0 využíval pro ověření návratové adresy tzv. XRDS dokument, který poskytovatel na svých stránkách zveřejňuje a návratovou adresu do něj vyplní. Poskytovatel identity (např. mojeID) si pak před přesměrováním uživatele na návratovou adresu tento dokument stáhne a ověří její správnost. Vlastní protokol ale toto ověření nevynucuje. Nevynucuje ani HTTPS spojení při stahování zmíněného dokumentu ani zabezpečení DNSSEC, a tedy nechává bezpečnost na libovůli poskytovatele služby. OpenID Connect na to jde úplně obráceně. Programátoři, kteří implementují do systémů poskytovatelů služeb přihlášení přes mojeID pomocí tohoto nového protokolu, se v tomto blogpostu dozví, jakou změnu jsme pro ně připravili.

O protokolu OpenID Connect jsme na blogu již psali. Jedná se o nejnovější protokol pro jednotnou autentizaci z dílny organizace OpenID Foundation a tento protokol je možné použít pro implementaci přihlášení přes naší službu mojeID v libovolných internetových službách. Jednou z novinek spojenou se vznikem nového protokolu je i program certifikace implementací tohoto protokolu. Cílem certifikace je ještě více podpořit interoperabilitu služeb na Internetu, které se rozhodnou tento protokol používat. Jako první nastartovala organizace OpenID Foundation program certifikace autentizačních serverů. Do tohoto programu jsme se zapojili i my se službou mojeID a jsem rád, že můžu oznámit, že mojeID certifikaci získalo.

Služba mojeID byla od svého vzniku v roce 2010 úzce spjata s autentizačním protokolem OpenID 2.0. Tento protokol byl pro nás v té době nejlepší volbou, protože kombinoval jednoduchost implementace a dostupnost knihoven pro různé programovací jazyky. OpenID 2.0 ale není jediný autentizační protokol. O některých dalších, jako například o protokolu SAML nebo OpenID Connect, jsem psal i na našem blogu. Zejména protokolu OpenID Connect, jehož standardizace byla dokončena na začátku loňského roku, věští analytikové slibnou budoucnost. No a dobrou zprávou je, že mojeID již není „jednojazyčné“, ale dokáže se domluvit s poskytovateli služeb i těmito dalšími protokoly.

Je to více než rok, co jsem poprvé psal o nové verzi OpenID protokolu nazvané OpenID Connect. Jeho vývoj se od té doby samozřejmě o dost posunul. Před necelým měsícem byl dokončen další významný milník v návrhu této sady specifikací a to je určitě příležitost zmínit se o aktuálním stavu. Pro připomenutí, OpenID je otevřený protokol pro jednotné přihlašování a jeho nová verze Connect je postavena nad moderním autorizačním protokolem OAuth 2.0. Oproti předchozí verzi OpenID 2.0 jsou jeho předností například mnohem jednoduší implementace, připravenost pro mobilní platformy anebo možnost použít email jako přihlašovací jméno.

Práce na novém protokolu začala v březnu 2010 a nyní byl publikován druhý tzv. Implementers Draft – tzn. verze specifikací, která prošla připomínkováním několika implementátorů. Kromě toho, že se průběžně vyvíjené implementace testují v rámci rozsáhlých testů interoperability, existuje již několik produkčních nasazení, kde je možné Connect použít a to např. Google, PayPal nebo Ping Identity. V tuto chvíli asi nejvíc postup blokuje finalizace některých specifikací, na kterých Connect závisí a které jsou vytvářeny podobně jako OAuth 2.0 na půdě IETF. V této organizaci je bohužel odhadováni termínů velká loterie. Přesto existuje orientační plán, při jehož splnění by finální verze specifikací měla být vydána v prosinci letošního roku.

Za vývojem všech OpenID specifikací stoji OpenID Foundation, která sdružuje společnosti jako Microsoft, Google nebo Facebook; vydávání nových specifikací se zde řídí přesnými pravidly. Finální verzi musí členové nakonec odhlasovat. Nová verze OpenID není jedna ucelená specifikace. Naopak, součástí balíku je 8 dokumentů pro jednotlivé oblasti a tyto ještě navíc navazují na řadu dalších specifikací, které nejsou specifické pro OpenID a jejichž vývoj probíhá v rámci IETF. Pojďme si tedy  projít jaké jsou základní stavební bloky OpenID Connect.

Spodní vrstvu tvoří víceúčelový autorizační protokol OAuth. Ten má v zásadě za úkol předat mezi třemi entitami (uživatelem, autorizačním serverem a službou) souhlas s nějakou akcí.  Specifikace tohoto protokolu ve verzi 2.0 vznikala v rámci pracovní skupiny OAUTH při IETF a po dvou letech práce nakonec vyšla loni na podzim v podobě dvou standardů RFC6749 a RFC6750. Bylo kolem toho hodně dusno, protože jeden z autorů původní verze protokolu, který tento protokol do IETF přinesl, dost ostře s finální verzí nesouhlasil. Nakonec hlasitě zkritizoval všechno, co bylo dosaženo, včetně fungováni IETF a od druhé verze protokolu se distancoval.

Pracovní skupina vydáním dvou RFC neskončila a pracuje na dalších rozšířeních protokolu. Pro Connect jsou nejdůležitější dvě. První z nich přidává automatickou registraci služeb. V základní verzi protokolu se totiž předpokládá, že každá služba bude svým autorem manuálně registrována k autorizačnímu serveru. Jedna z vlastností OpenID je, že služby mohou využívat předem neznámý OpenID server, což je možné právě pouze s využitím automatické registrace.

Druhé rozšíření přidává k základní verzi protokolu přenos tzv. prohlášení o identitě (assertion). Autorizační server v něm kromě své identifikace uvede i jednoznačnou identifikaci přihlášeného uživatele. Právě díky této identifikaci pak může služba ve své vlastní evidenci uživatele najít a umožnit mu přihlášení. Podobně jako velké množství dalších specifikací vznikajících v IETF i zde se začal prosazovat jazyk JSON na úkor XML. Connect bude také využívat prohlášení v jazyku JSON a označované jako JWT (JSON Web Token).

Aby bylo ono prohlášení zmíněné v předchozím odstavci důvěryhodné, musí být podepsané. Jazyk JSON je ovšem poměrně mladý a tak neobsahuje některé vlastnosti, které jsou například v XML již dlouhá léta běžné. Jednou z těchto vlastností jsou právě digitální podpisy, které v XML řeší prověřené rozšíření xmldsig . Tento nedostatek se v IETF snaží napravit pracovní skupina JOSE. Skupina pracuje na čtyřech dokumentech a to JSON Web Algorithms (JWA), JSON Web Encryption (JWE), JSON Web Key (JWK) a JSON Web Signature (JWS). Bohužel ale neschopnost konsenzu finální vydání RFC oddaluje a skupina autorů OpenID Connect je z toho poměrně rozladěna.

Poslední klíčovou závislostí, která vzniká v IETF, tentokrát v pracovní skupině APPSAWG, je protokol webfinger. Tento protokol hraje roli ve fázi OpenID komunikace označované jako „discovery“. Služba se při ní snaží z poskytnutého identifikátoru zjistit, jaká je adresa OpenID serveru se kterým má pro přihlášení komunikovat. Rozhodnutí používat webfinger místo vlastního řešení SWD (Simple Web Discovery) bylo poměrně významnou změnou ve specifikacích OpenID Connect a došlo k ní letos v lednu. Protokol webfinger bude univerzální protokol pro zjišťování dodatečných informací o nějakém zdroji na internetu. Např. pro přihlášení uživatele provede služba po zadání uživatelského jména user@example.com standardní http dotaz na example.com/.well-known/webfinger?resource=acc://user@example.com. Výsledek ve formě JRD (JSON Resource Descriptor) bude obsahovat mimo jiné i adresu OpenID serveru, se kterým se spojit.

Pro zájemce o podrobnější informace o OpenID Connect doporučuji souhrnnou prezentaci jednoho z autorů. Jak je vidět, autoři OpenID Connect si dali nelehký úkol vytvořit standard, který bude skládat obecné technologie do použitelného celku. Historický vývoj specifikací pěkně ilustruje následující obrázek:

OpenID Connect je technologie, od které si svět správců identit hodně slibuje a jejíž vývoj byl také oceněn významnou cenou na loňské konferenci European Identity & Cloud Conference. Jeho vývoj se posouvá, byť možná pomalým tempem, ke svému cíli. Nezbývá než doufat, že tato technologie své příznivce nezklame a podaří se jí po jejím dokončení rychle rozšířit mezi služby na internetu.

Jaromír Talíř

Přestože je téma digitální identity (a souvisejících distribuovaných „single sign-on“ přihlašovacích mechanismů) staré možná jako internet sám, troufám si tvrdit, že jeho největší okamžiky teprve přijdou. Po úspěších centrální správy identit, které v současnosti ukazují veřejné služby jako Facebook, nebo Google+, přirozeně pokukují propagátoři různých forem e-governmentu. V něm mohou některé mechanismy fungovat na podobných principech, přičemž přidaná hodnota je určitě validita údajů identit, které veřejné služby mohou jen těžko dosáhnout. Nesmělé náznaky v podobě elektronických občanek u nás, připravované rozhraní k datovým schránkám, ale i aktivity vlád v celém světě (německý projekt de-ident, americká strategie pro důvěryhodné identity v kyberprostoru NSTIC, nebo projekt evropské identity STORK) naznačují, že tato oblast v blízké době zažije velké změny. Bylo by jistě užitečné, kdyby jednotlivé implementace místo proprietárních řešení vycházely z konsensuálních standardů, které i v této oblasti existují a není jich málo.

Jednou z platforem, na které kooperují autoři těchto standardů, je například Internet Identity Workshop. V rámci pravidelných konferencí této platformy, které se konají dvakrát ročně si zástupci nejrůznějších standardizačních organizací vyměňují informace o novinkách ve svých produktech. Na následujících řádcích bych rád shrnul nejvýznamnější standardy na tomto poli a upozornil na nejnovější aktivitu, která se objevila v průběhu minulého roku.

Asi nejstarším zástupcem  protokolů této kategorie je SAML. Jeho první verze pochází z roku 2002 a zatím poslední verze z roku 2005. Za tento, na jazyku XML založený, protokol nese odpovědnost standardizační organizace OASIS, známá svými dalšími „XML aktivitami“ jako Docbook nebo DITA. SAML se poměrně pevně usadil v akademickém světě. Například u nás je to protokol, na kterém funguje Česká akademická federace identit známá pod zkratkou EduID,  provozovaná sdružením CESNET. Takže pokud máte účet v systému své vysoké školy, s velkou pravděpodobností můžete používat SAML pro přihlašování u systémů poskytovatelů služeb, které jej podporují. Těch bohužel není mnoho a zejména jsou to opět akademické instituce. Jedním z těchto poskytovatelů služeb by, alespoň podle dokumentace, měly být i GoogleApps.

V roce 2005 se na poli standardů objevil protokol OpenID. Jeho jádro prošlo vývojem a ustálilo se na verzi 2.0 z konce roku 2007. V průběhu dalších zhruba tří let si získal velkou popularitu a podporovali ho i velcí hráči jako Google nebo Microsoft. Za účelem rozvoje tohoto standardu vznikla organizace OpenID Foundation, která sdružuje jak zástupce poskytovatelů identit, tak poskytovatelů služeb. U nás byl dlouho jediným větším průkopníkem této technologie Seznam.cz. Předloni jsme si OpenID jako komunikační protokol zvolili i my s naší službou ověřených identit mojeID. Důležitou vlastností tohoto protokolu je možnost standardizované výměny atributů identity.

Při práci na implementaci OpenID do služby Twitter vznikla další významná technologie pojmenovaná OAuth. Na rozdíl od OpenID má tato technologie jako cíl umožnit poskytovatelům služeb zabezpečený přístup k nějaké obecně libovolné sadě funkcí, kterou jiná služba nabízí. První draft byl publikován v roce 2007 a jeho vývoj se v průběhu roku 2010 přesunul na půdu asi nejvýznamnější internetové standardizační organizace IETF. V této době probíhá práce na dokončení verze 2.0 standardu, jehož finální vydání ve formě RFC je „snad“ otázkou příštích několika týdnů. Po Twitteru přijal tuto technologii za vlastní také Facebook a nakonec ji do repertoáru svých autentizačních mechanismů přidal i Google.

Co se týká srovnáni OAuth a OpenID tak OAuth sice nabízí asi jen polovinu vlastností které má OpenID, ale na druhou stranu to dělá mnohem lépe. Vzhledem k tomu vzniklo v průběhu posledních dvou let několik pokusů, jak zkombinovat to nejlepší z nich do ideálního výsledku. Těchto několik pokusů se nakonec spojilo dohromady a v polovině roku 2011 byl prezentován výsledek v podobě specifikace nazvané OpenID Connect. Toto řešení ve své „spodní“ části využívá OAuth 2.0 a obaluje ho vlastnostmi specifickými pro OpenID. Zajímavou změnou je i následování trendu a nahrazení jazyka XML na příslučných místech jazykem JSON. Od prosince je návrh standardu v připomínkovém řízení a pokud vše půjde hladce, mohli bychom se už letos dočkat jeho finální verze. Za touto specifikací stojí všichni velcí hráči jako Facebook, Google i Microsoft což jí dává poměrně dobré vyhlídky na její budoucí rozšíření.

Jak je vidět, ve světě digitálních identit je hodně živo a my věříme, že minimálně u nás nechá služba mojeID v této diskuzi viditelný otisk. Rodina použitelných specifikací je široká a rozhodně neumírá. Nové generace těží ze zkušeností svých předchůdců a většinou přidávají nové pohledy a nové myšlenky. Z pohledu mojeID samozřejmě nepřestáváme sledovat aktuální vývoj. Charakter této služby nijak nebrání tomu použít několik přístupových technologií paralelně a tím nabídnout poskytovatelům služeb větší výběr možností implementace. Pokud zjistíme vzrůstající poptávku po některém ze zmiňovaných protokolů, pokusíme se této poptávce vyhovět.

Jaromír Talíř

Ve svém nedávném blogpostu o identitách jsem zmiňoval finišující proces standardizace protokolu OAuth 2.0 směřující do podoby RFC a novou iniciativu v podobě protokolu OpenID Connect. Tyto technologie a digitální identity vůbec budou zdá se jedním z důležitých témat blížícího se setkání IETF 83. Jako první se iniciativy chopil ISOC, který na příští úterý ohlásil panelovou diskuzi na téma Authentication and Authorization: Next steps for OpenID and OAuth. Vzápětí se na čtvrteční program konference dostala sada prezentací následovaná otevřenou diskuzí na téma Beyond HTTP Authentication: OAuth, OpenID, and BrowserID. Na oboje jsem velice zvědavý, stejně tak na výsledek, které obě akce přinesou.

Na IETF se tyto technologie objevují ještě v jednom ne úplně nevýznamném kontextu. V pracovní skupině KITTEN (Common Authentication Technology Next Generation) se například řeší, jak využít OpenID, OAuth nebo SAML pro autentizaci v běžných internetových protokolech používajících standardy GSS a SASL. Nemusí tak být úplně nesmyslná představa, že jednou bude možné se pomocí OpenID přihlašovat i do LDAPu, IMAPu a dalších. Třeba to nebude trvat dlouho, nechme se překvapit.

Jaromír Talíř