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íř