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.
Každý poskytovatel služby implementující protokol OpenID Connect musí nejprve svoji návratovou adresu zaregistrovat u poskytovatele identit. Při této registraci obdrží údaje client_id a client_secret, které posléze používá pro svoji identifikaci směrem k poskytovateli identit. V průběhu autentizačního procesu poskytovatel identit ověří totožnost poskytovatele služby včetně informace, zda-li je požadovaná návratová adresa zaregistrována. Jak taková registrace probíhá? Kdo někdy implementoval přihlášení přes Google nebo Facebook ví, že tyto služby mají obvykle nějakou vývojářskou konzoli, kam je možné se přihlásit svým účtem a novou registraci si jednoduše vyklikat. Na konci procesu pak vývojář zkopíruje vygenerované client_id a client_secret do své aplikace. Tomuto procesu se říká statická registrace poskytovatele služby.
Standard OpenID Connect definuje ještě jednu možnost a tou je dynamická registrace služby. Pokud poskytovatel identit tento proces umožňuje, zveřejní adresu HTTP rozhraní, na které je možně zaslat POST požadavek obsahující základní údaje a potřebné údaje jako client_id a client_secret jsou vráceny ve formátu JSON v odpovědi na tento požadavek. Pro univerzálně psané nástroje, které chtějí používat obecně libovolného poskytovatele identit je toto jediná cesta, jak se na předem neznámého poskytovatele identit připojit. Implementace OpenID Connect s využitím knihoven, které tuto dynamickou registraci umožňují, je pak velice přímočará. Jednu takovou knihovnu pro snadné napojení na mojeID napsanou v JavaScriptu jsme zveřejnili i my. Dynamická registrace tedy byla pro mojeID logicky první volbou.
Problém trochu nastává pokud vývojář implementující přihlášení přes mojeID použije knihovnu, která tuto dynamickou registraci nepodporuje. V takovém případě je nutné aby tento vývojář např. v příkazové řádce za použití nástrojů jako curl nebo wget vygeneroval příslušný HTTP POST požadavek a vytáhl potřebné údaje z odpovědi. Toto není příliš komfortní. Druhý problém dynamické registrace je, že některé knihovny implementované například jako JavaScript v prohlížeči, provádějí tuto registraci s každým načtením stránky. V databázi registrací tak vznikají tisíce záznamů, které mají ale smysluplnou dobu existence pouze pár minut. Abychom tyto záznamy mohli odmazat, bylo by dobré je rozeznat od těch, které vznikly za účelem dlouhotrvající registrace.
Výše popsané problémy nás přiměly implementovat také statickou registraci přes webové rozhraní. Dynamická registrace bude mít na rozdíl od statické jasnou dobu expirace a po jejím uplynutí budeme záznamy o registraci promazávat. V první fázi se jedná o jednoduchý editor uložených záznamů navázaných na přihlášeného uživatele mojeID. Tento editor je dostupný na adrese, která je zveřejněná v dokumentaci implementace mojeID do systémů poskytovatelů služeb. Drobným nedostatkem je, že editor je přímo přístupný pouze tímto odkazem a uživatel musí být přihlášený. Editor umožňuje služby přidat, odebrat nebo změnit parametry zaregistrované služby, jak je vidět na následujícím obrázku.
Vložené záznamy jsou navázané na jednoho konkrétního uživatele mojeID. Aktuálně analyzujeme možnost rozšířit tento mechanismus tak, aby každá služba mohla mít více takových „správců“ a nebylo při potřebě rychlé změny nutné čekat na jednoho konkrétního člověka. V budoucnosti bychom rádi obdobným způsobem přidali možnost správy nastavení parametrů pro služby využívající SAML protokol. Tyto služby jsou aktuálně odkázané na e-mailovou komunikaci s naší technickou podporou, což jistě není ideální.