Přejít k navigační liště

Zdroják » Různé » OpenID: Historie, terminologie a mechanismus autentizace

OpenID: Historie, terminologie a mechanismus autentizace

Články Různé

V tomto článku si popíšeme podrobněji na fungování autentizační metody OpenID. Řekneme si něco o její historii, ujednotíme si terminologii používanou ve světě OpenID a ukážeme si mechanismus uživatelské autentizace. Podíváme se také na dva zajímavé rysy, které ukazují možnou sílu OpenID.

Historie verzí OpenID

První verze specifikace OpenID (verze 1.0) obsahovala některé nejednoznačnosti, kvůli kterým byla brána jako neformální návrh. Problémy této neformální specifikace opravila specifikace 1.1, která se tak stala vlastně první prakticky použitelnou OpenID specifikací.

V prosinci 2007 byla podepsána a vydána specifikace OpenID 2.0, která je v současné době aktuální. Verze 2.0 přinesla několik vylepšení, mimo jiné například:

  • Jednotnou podporu pro rozšíření OpenID protokolu
  • Podporu větších požadavků a odpovědí, které by se nevešly do URL (zavedena možnost předávání dat metodou HTTP POST)
  • Možnost zadat identifikátor OpenID providera namísto identifikátoru uživatele
  • Podporu obecných rozšiřovacích atributů

Většina klientských knihoven a velké množství poskytovatelů podporuje OpenID 2.0, přesto pokud chceme implementovat podporu přihlašování přes OpenID, měli bychom počítat i s poskytovateli, kteří implementují protokol 1.1. Oficiální OpenID knihovny tuto podmínku naštěstí splňují.

Zajímavosti OpenID protokolu 2.0

Ve výše uvedeném popisu novinek, které přináší OpenID 2.0, jsou naznačeny dvě věci, o nichž se domnívám, že zaslouží samostatnou zmínku. Jedná se o rozšíření a identifikátory poskytovatelů.

Simple Registration Extension

Již se specifikací OpenID 1.1 přišlo i jedno zajímavé standardizované rozšíření protokolu, nazývané Simple Registration Extension. OpenID totiž v čisté podobě nenabízí nic víc než ověření identifikátoru (tedy informaci „Ano, tento uživatel je oprávněn prokazovat se tímto identifikátorem“) – tedy v podstatě totéž, co nabízí např. ověření Live ID. Simple Registration přidává k tomuto mechanismu dodatečné informace, které si může klient vyžádat a poskytovatel mu je může předat – jsou to pole pojmenované jako openid.sreg.*, která obsahují jméno, přezdívku, adresu a podobné informace (viz popis Simple Registration Extension). Na tomto místě je vhodné připomenout, že jde o volitelné informace, které poskytovatel mít nemusí nebo je nemusí předat, pokud si to uživatel nepřeje.

V OpenID 2.0 je mechanismus rozšíření dále zobecněn a upraven – je přidán koncept jmenných prostorů, který řeší případné konflikty názvů různých rozšíření.

Identifikátor poskytovatele

OpenID 2.0 rovněž přišlo s novinkou, zvanou identifikátor poskytovatele. Jde o jakýsi zástupný identifikátor, odkazující na poskytovatele. Pokud uživatel zadá takový identifikátor, je před procesem zjišťování (Discovery) poskytovatel nejprve dotázán na uživatelův identifikátor; autentizace pak pokračuje s tímto identifikátorem. Tento koncept přináší některé zajímavé možnosti:

  • Poskytovatel může třeba všem svým uživatelům dát stejný identifikátor. Například root.cz by mohl poskytnout všem svým uživatelům univerzální identitu openid.root.cz, se kterou by se mohl každý zaregistrovaný uživatel přihlásit na libovolné stránce, která podporuje OpenID.
  • Je možné například vytvořit „anonymní poskytovatele“, kteří budou pro jednoho uživatele posílat každé službě unikátní OpenID. Uživatel se tedy bude vždy přihlašovat např. jako „anonymni-openid.com“ a poskytovatel mu pro každou zaregistrovanou službu vytvoří unikátní identifikátor ve tvaru f5ad8qx2yw5.a­nonymni-openid.com. Znemožní se tím sledování uživatelů podle jejich identifikátoru, což jistě mnozí ocení.

Terminologie

Před tím, než se vůbec podíváme, jak OpenID funguje, si musíme ujasnit některé termíny. Česká terminologie v této oblasti není zatím nijak ustálená, proto použiji buď překlad nebo opis, a u termínů uvedu originální tvar, dohledatelný v OpenID specifikaci.

Identifikátor
V terminologii OIS nazýván Identifier. Je to buď URI s protokolem http nebo https (URL), nebo XRI (o tom podrobněji až někdy jindy, zájemce odkazuji na specifikaci).
Poskytovatel
Též Provider, v terminologii OIS OpenID provider. Server, který poskytuje Klientovi potvrzení o tom, že konkrétnímu uživateli patří konkrétní identifikátor. Někdy se lze setkat s termínem Správce identit nebo poskytovatel identit. Zkratka: OP
OP Endpoint
Celým jménem OpenID Provider Endpoint URL, neboli koncový bod OP – absolutní http nebo https URL, na kterém poskytovatel přijímá požadavky od klientů.
Klient
Též Konzument, v originální terminologii OIS je nazýván Relying Party. Tento výraz nemá ustálený český termín; v doslovném překladu znamená „ta strana, co se spoléhá“ – myšleno spoléhá se na ověření identity od OP. Nejčastěji jde o web, který implementoval možnost přístupu k vlastním službám přes OpenID. Ve specifikaci je používána zkratka RP.
Uživatelský klient (Prohlížeč)
V terminologii OIS nazýván User-Agent. Jde o webový klient, který implementuje protokol HTTP/1.1 (v praxi nejčastěji webový prohlížeč). Aby se označení nepletlo s OpenID klientem, tak budeme používat označení „Prohlížeč“.
OP identifikátor
Identifikátor poskytovatele.
Uživatelem poskytnutý identifikátor
Neboli User-Supplied Identifier USID – identifikátor, který uživatel zadal na webu RP (nebo který si vybral na stránkách Poskytovatele). V průběhu přihlašování může uživatel zadat buď svůj identifikátor, nebo OP identifikátor – v takovém případě mu Poskytovatel nabídne možnost vybrat si identifikátor, jakým chce být přihlášen.
Přidělený identifikátor
V originální terminologii OIS pod názvem Claimed identifier. Identifikátor, o němž uživatel prohlašuje, že mu patří, že je jeho. Celý mechanismus OpenID slouží k ověření tohoto nároku, tohoto tvrzení. Přiděleným identifikátorem je míněn USID po normalizaci (pokud byla zadána URL adresa) nebo CanonicalID, pokud byl zadán XRI.

Ověření krok za krokem

OpenID ověření probíhá v několika krocích, kdy spolu komunikují prohlížeč, poskytovatel a klient. Na začátku je požadavek od uživatele, který zadá svůj identifikátor (USID), na konci je informace o tom, zda se dotyčný uživatel tímto identifikátorem prokazuje oprávněně.

Schema průběhu autentizace pomocí OpenID

Přehled kroků probíhajících při autentizaci pomocí OpenID. Jednotlivé kroky jsou popsány dále v textu.

  1. V prvním kroku uživatel – slovy specifikace – sdělí (pomocí prohlížeče) svůj identifikátor RP. Laicky (a míň šroubovaně) řečeno: Napíše svůj identifikátor do příslušného políčka ve formuláři na klientových stránkách a odešle.
  2. Klient normalizuje (viz specifikace) dodaný identifikátor. Po jeho normalizaci se snaží získat adresu OP Endpointu zjišťovacím procesem (ve specifikaci nazývaný Discovery)
  3. (Volitelný) Klient a poskytovatel si vytvoří tzv. přiřazení (Association, viz specifikace) – pomocí Diffie-Hellman algoritmu (RFC2631) si vymění klíč, kterým poskytovatel bude podepisovat odpovědi a klient ověřovat jejich pravost. Tento krok odstraňuje nutnost dalších dotazů na ověření podpisu při každém autentizačním požadavku či odpovědi.
  4. Klient přesměruje uživatelův prohlížeč na stránky poskytovatele buď pomocí HTTP redirektu nebo JavaScriptem a v URL předá autentizační požadavek (viz specifikace)
  5. Poskytovatel ověří, zda je uživatel oprávněn prokazovat se daným identifikátorem a zda si to opravdu přeje. Standardně OpenID nijak nepředepisuje způsob, jakým to má poskytovatel dělat – jestli ověří uživatele jménem a heslem, SMS kódem, elektronickým klíčem či biometrickými údaji, to záleží jen na něm. V budoucnu bude ale možné pomocí rozšíření PAPE požadovat vyšší nároky na ověření – např. požadovat vícenásobné potvrzení identity či požadovat, aby alespoň jeden způsob ověření byl fyzický (biometrické údaje, hardwarový klíč apod.) Specifikace PAPE je nyní ve stádiu návrhu a členové OpenID nadace o ní právě v těchto dnech hlasují.
  6. Poskytovatel přesměruje uživatelův prohlížeč zpět na klientovy stránky a zároveň předá (v URL) informaci o tom, zda je autentizace potvrzena, nebo zda selhala.
  7. Klient ověří informace předané Poskytovatelem: Zkontroluje návratové URL, informace o endpointu, zkontroluje nonce kód (unikátní kód požadavku) a ověří podpis, buď pomocí společného klíče, dohodnutého v kroku 3 (přiřazení klient-poskytovatel), nebo dodatečným dotazem na poskytovatele.

Závěr

Na závěr stručné shrnutí: V současnosti je aktuální OpenID verze 2.0. OpenID ověření probíhá v několika krocích, kterých se účastní uživatel, klientská služba a poskytovatel OpenID. Specifikace nestanovuje, jakým způsobem má poskytovatel OpenID ověřit, zda je uživatel oprávněný prokazovat se danou identitou; v blízké budoucnosti však bude možné požadovat určitou úroveň tohoto ověření pomocí rozšíření PAPE. Předávání informací o uživateli není základní součástí protokolu, je jeho rozšířením. Protokol verze 2.0 má možnosti, jak zabránit sledování uživatelů podle jejich identifikátoru, a zároveň zachovat jednotné přihlášení.

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

Příště konečně odbočíme od šedivé teorie a na příkladu si ukážeme, jak lze v několika snadných krocích implementovat OpenID přihlašování na web.

Kolik OpenId identit používáte?

Komentáře

Subscribe
Upozornit na
guest
28 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Ja.

Mne sa to furt nezdá. Mať niekde uloženú celú svoju identitu, to si pýta riadny problém. Nech je to technicky akokoľvek prepracované.

danaketh

Chápu správně, že se Vám nezdá mít svou identitu uloženou na jednom místě a připadá Vám mnohem bezpečnější (a pohodlnější) mít jich 50 po různých diskusích a webech? Navíc každou jinou, podle toho jak byl volný login + pokaždé vkládat svůj email a podstupovat otravné ověření jeho pravosti.

U OpenID si zvolíte jaké údaje o Vás jsou v identitě vidět a pokud chcete, prostě nezobrazíte žádné. Kromě toho nemusíte nikam vkládat citlivé údaje. Já mám uloženo pouze jméno, město, stát a email. Na mnoha webech kolikrát nemáte šanci před ostatními (často navíc ani před roboty) skrýt své informace. S OpenID o Vás nikdo nemusí vůbec nic vědět. Budou vědět jen že to jste Vy ale budou mít jen takové informace, jaké jim sám dáte, nikoliv jaké si po Vás na vyžádají nějakým registračním formulářem.

Anonymní

No to nemám (skrývání informací) ani teď s OpenID, spousta webů spolu s registrací přes OpenID vyžaduje další informace jako e-mail, který si navíc ověřují dodatečně apod. OpenID je čistě na ověření správnosti hesla a jména, takže ověření autorizace.

Christof

To je chyba webu. Např. Drupal má podporu OpenID takovou, že při přihlášení přes OID už nemusíš nic dalšího vyplňovat.

Anonymní

Právě Drupal je zářivým příkladem softwaru, který OpenID využívá pouze k ověření jm=na/hesla (autorizační funkce), ale již ne jako profil. Drupalu nemůžete poslat jenom identitu (jméno), musíte mu třeba poslat i e-mail apod. Přitom nechápu, proč bych měl provozovateli dávat e-mail, když zapomenu heslo, pošle mi jej moje OpenID certifikační autorita.

Christof

To jo, ale to je kvůli vnitřní struktuře – ke každému uživateli musí být v databázi e-mail. Ale myslel jsem to tak, že se nemusí vyplňovat registrační formulář, stačí OpenID a Drupal si vytáhne e-mail a nick, které potřebuje.

cubeek

Zdravím a děkuji za seriál o mikroformátech.
Zajímala by mě jedna věc – pokud uchovámám citlivé informace o svých zákaznících ve své DB a nabídnu jim možnost se autorizovat do mé aplikace pomocí OpenID, nejsem pak v konfliktu se zákonem 101/2000 sb.? Třetí strana (OpenID provider) pak dostává přístup k datům mých zákazníků.

danaketh

Martin mne kdyžtak opraví kdybych to popletl…

OpenID provider nedostává nic. Proč taky? K čemu by OpenID provider potřeboval například adresu klienta nebo údaj o velikosti jeho ponožek? OpenID slouží jako autorizační metoda, žádná data o nikom neshromažďuje.

Stejně tak pokud provážete již existující účet s OpenID, tak zde stále dochází pouze k ověřování uživatele a jeho oprávnění přístupu k webu. Konečně při implementaci můžete připojit script na logování komunikace a sám si ověřit jaká data OpenID sbírá :)

cubeek

Chápu, že si OpenID provider nemůže nic nasbírat s mých dat o mém zákazníkovi, ale má v ruce jeho údaje o přihlášení a může se tudíž přihlásit ke mě a podívat se, co tam mám. A rozumím, že záleží na serióznosti providera. Sám doufám, že to není tak snadné, rád bych OpenID nasadil.

danaketh

Co se týká těch přihlašovacích údajů, tak odpověď nechám Martinovi. Tak dalece tomu nerozumím a netuším, zda si vůbec něco ukládá. Já mám pocit, že si nic neukládá, protože jsem nikdy na OpenID nezadával heslo k žádné své registraci, vždy jen heslo k OpenID.

Jan R.

Přihlásit se může, stejně tak se ale může "přihlásit" poskytovatel jeho emailu pomocí funkce zapomenuté heslo.

Look Smog

Provider sbírá pouze Trust Root URL, tedy URL rootu Vašeho webu.

Heslo je u něj v databázi zašifrováno, takže jediný způsob, jak by se mohl dostat k Vám na web pod údaji Vašeho zákazníka je podle mě obcházení vlastního systému nebo odchytávání uživatelových dat (pokud nepoužívá SSL).

P.S. – Sám jsem si knihovnu pro OpenID napsal, takže toho o tom vím relativně dost. Jediné dva údaje, které je zákazník povinen uvést u OpenID providera, jsou heslo a email. Nic víc nepotřebuje a neshromažďuje.

Ale toto se týká pouze solidních providerů. Pokud se klient zaregistruje u špatného providera, tak to má na vlastní nebezpečí, ale rozhodně se mu do ruky nedostanou, žádné údaje z Vaší databáze, pokud mu je sám nepošlete.

benzin

Heslo uzivatele je ulozene jako hash pouze tehdy pokud si to provider OpenID pral. (ale to je stejne nepodstatne)

Ve skutecnosti pokud moje sluzba nebude pozadovat dodatecne heslo ma provider OpenID vse co potrebuje. Protoze moje sluzba se od nej pouze dozvi jestli se jedna skutecne o toho uzivatele. A provider rekne ano kdyz on chce (standartne po zadani hesla, ale proc treba ne, po zadani admin hesla OpenID providera?)

Prestavte si to jako kdyz za vama do obchodu prijde zakznik. Rekne ja jsem Pepa Novak a na uctu mam 5 000 Kc muzu si u vas nakoupit? A vy se zeptat, jak vim ze jde Pepa Novak? On rekne, to vam povi Filip Zhorelec, tady mate na neho kontakt. Vy zvednete telefon podate ho zakaznikovi, od nadyktuje svoji identifikaci a preda vam telefon, na druhem konci vam Filip Zhorelec rekne, ano skutecne komunikujete s Pepou Novakem.

Jakou informaci mate? Vite jiste, ze komunikuj s Pepou Novakem? Ne vite jenom, ze ten o kom telefoni seznam tvrdi ze je Filip Zhorelec vam rekl, ze komunikujete s Pepou Novakem. Zatimco vidavatel telefoniho seznamu (certifikatu) je relativne duveryhodny, tak Filip Zhorelec, muze byt zcela neduveryhodny a zitra vam rekne o komkoli jinem ze take on je Pepa Novak.

u1

1) Nezda se Vam, ze pokud bude mit provider OpenID kompletni historii "URL rootu" vsech webu, ktere jste navstivil (a autentifikoval se tam pomoci OpenID), tak se jedna o dost citlive informace, ktere nelze sverit kazdemu? Paradoxne pokud se autentifikujete primitivne na kazdem webu zvlast, tato slabina nevznika. Ano, Vas poskytovatel Internetu zna kazdou IP adresu, s kterou jste komunikoval ale celkem nic s tim nenadelame (az na TOR …). Ale rozdil vidim v tom, ze typicky poskytovatel OpenID (Seznam, Google, …) je spolecnost orientovana na obchod s informacemi ve velkem a snaha tyto informace obchodne vytezit se od ni necha s jistotou ocekavat.

2) Nemuze ziskat poskytovatel OpenID kompletni historii Vasich URL, pokud se bude autentifikovat kazda stranka (nevim jestli je to bezne)?

Jan Kodera

1) Pokud tímto trpíte, tak si založte vlastního open-id providera. Tím budete mít kontrolu nad svými daty a ještě budete moci využívat výhody open-id. Nicméně myslím, že Google by byl šokován kdyby zjistil, že chodíte také na facebook a občas na spolužáci.cz a když se chcete hodně odvázat jdete na diskutovat pod videa na stream.cz.

Ale čistě obecně, pokud chodíte na nějakou stránku u které nechcete, aby to o vás kdokoliv věděl, tak se tam prostě nepřihlašujte pomocí open-id. Tímto způsobem získáte zpět kontrolu nad svým soukromím.

Martin Hassman

Dokud budou všechny prohlížeče náchylné k CSS exploitu, tak openid neopenid, informace o tom, které weby navštěvuji, se stejně nějakým způsobem dostane ven (o něco komplikovanějším, ale zase ji mají k dispozici skoro všichni).

benzin

No tady se ani tak nejedna o identifikaci uzivatele v blozich, diskusich a chatech. I na jine sluzby, kde hlavnim smyslem registrace, je uchovavani uzivatelskeho nastaveni pro uzivatele.

V pripade, ze ale hodlate komunikovat se zakaznikem a pomoci vaseho systemu si sdelovat duverne informace obchodniho charakteru, tak je OpenID zcela nevhodne. Stejne tak je naprosto nevhodne pro pouziti vsude tam, kde je vyzadovan souhlas podle zakona 101, protoze tam jde take o duverne informace.

Takze jednoznacne OpenID ano, tam kde informace nejsou duverne. OpenID ne, kde se pracuje s duvernymi informacemi.

benzin

Ano presne tak, z pohledu men jako poskytovatele sluzby, tim akorat do hry dostavam dalsi moznou bespecnostni diru, protoze i poskytovatel. (ps. zapomenute heslo po mailu posle i openId provider).

Tam kde mne to netrapi je to v pohode, nicmene je to proste dalsi dira a dalsi okruh lidi, kteri maji pristup do me sluzby, aniz by k tomu byli opravneni.

P.S.: Prirovnal bych to ke zbranim. Proc mame nejake registry zbrani, kdyz se k nim pripadny zlocinec stejne dostane?

cubeek

Díky pánům Malému a benzinu za užitečné podněty, něco jsem nastudoval a už mám řekněme jasno.

LN

Stale mi neni jasna jedna vec – co kdyz nekdo vytvori autoritu "alwaysok.com", ktera bude vracet serveru automaticky TRUE (tedy vlastne nic nikdy overovat nebude). Jako server samozrejme nechci, aby se mi uzivatele overovali timto zpusobem – jenze to neovlivnim jinym zpusobem, nez whitelistem duveryhodnych autorit. A to zase popira myslenku "open".

Jinymi slovy – cele je to zalozene na predpokladu, ze useri budou volit duveryhodne autority. Jenze useri jsou prevazne BFU…

benzin

Krom toho musite vytvorit i seznam vsech certifikatu OpenID provideru, jinak se muze stat ze budete komunikovat s uplne nekym jinym.

benzin

Ano presne tak, tam kde neni bespecnost dulezita a jste ochotni odesilat hesla e-mailem to znaci v nezasifrovane podobe, tak tam nebude OpenID delat zadny problem.

Btw. ja sam vyvyjim jak aplikace ktere ucty nepouzivaji k nicemu vic, nez nejakemu ukladani nastaveni a pripadne vypocitavani bonusobych bodu. Pro OpenID super (proto mne taky zajima). Tak take vyvyjim aplikace, kde bych e-mailem heslo neposlal a sdeluji jej telefonicky, nebo poslanim SMS a presne tam je OpenID spatnym resenim.

P.S.: jenom si dejte pozor na to ze si OpenID provider a sluzba vymeni klice znamena pouze to ze jejich komunikaci nikdo nedposlechne, nikoli to ze by se tim autentifikoval OpenID provider. Pokud si nebudete udrzovat seznam certifikatu poskytovatelu OpenID, tak jedine co se tak maximalne z certifikatu dozvite, je ze ho nekdo (mozna duveryhodny) podepsal.

Martin Malý

"jenom si dejte pozor na to ze si OpenID provider a sluzba vymeni klice znamena pouze to ze jejich komunikaci nikdo nedposlechne, nikoli to ze by se tim autentifikoval provider." – já něco takového tvrdím? Já jsem psal (snad srozumitelně), že si dohodnou klíč, tím klíčem provider podepíše odpověď a klient si ověří validitu a integritu dat (namísto dalšího dotazování).

benzin

Netvrdite, jenom spousta lidi si mysli, ze certifikatem je zarucena pravost providera. Takze na to upozornuju, ze to tak neni.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.