OpenID: Historie, terminologie a mechanismus autentizace
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.
Seriál: Moderní internetové autentizační metody (7 dílů)
- Moderní internetové autentizační metody 19. 12. 2008
- Porovnání moderních autentizačních metod 23. 12. 2008
- OpenID: Historie, terminologie a mechanismus autentizace 30. 12. 2008
- Implementace přihlašování pomocí OpenID 6. 1. 2009
- OpenID: Identity, aliasy a vlastní poskytovatel 13. 1. 2009
- Implementace přihlašování pomocí Live ID 20. 1. 2009
- Webové autentizační metody: Kuriozity a novinky 27. 1. 2009
Nálepky:
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.anonymni-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ě.
Přehled kroků probíhajících při autentizaci pomocí OpenID. Jednotlivé kroky jsou popsány dále v textu.
- 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.
- 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)
- (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.
- 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)
- 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í.
- 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.
- 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.
Martin Malý
Začal programovat v roce 1984 s programovatelnou kalkulačkou. Pokračoval k BASICu, assembleru Z80, Forthu, Pascalu, Céčku, dalším assemblerům, před časem v PHP a teď by rád neprogramoval a radši se věnoval starým počítačům.
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é.
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.
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.
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.
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.
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.
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ů.
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á :)
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.
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.
Přihlásit se může, stejně tak se ale může "přihlásit" poskytovatel jeho emailu pomocí funkce zapomenuté heslo.
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.
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.
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)?
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.
ad 2 – jestli myslíte "historii vašeho pohybu po dané službě", tak nezíská, protože uživatel je autentizován pouze jednou, při vstupu do "chráněné oblasti". Je na službě, aby si zapamatovala, že jde o autentizovaného uživatele. Kdyby byl uživatel autentizován znovu na každé stránce, bylo by to neúnosné a nesmyslné.
Pokud máte na mysli "každou stránku = každý web", tak ano, může získat (a získává) seznam webů, na nichž jste se přihlásil. Pokud se budete pohybovat pouze po webech s přihlášením via OpenID, tak získá KOMPLETNÍ seznam.
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).
Hezké, možná to použiju v dalším díle Oblíbených Mýtů O OpenID. :)
V zásadě to je tak, jak píšete: Ano, neseriózní provider se teoreticky může přihlásit s OpenID identitou libovolného svého uživatele. To riziko tu je.
Ovšem na druhou stranu – internet je založen na důvěře. Věříte, že váš poskytovatel má správné údaje v DNS a že nemá důvod vám posílat falešné. Věříte, že hostingová firma nekouká do vašich mailů a do vašich databází. Věříte, že v systémech nejsou backdoors, kterými by do nich NĚKDO nahlížel. Věříte, že v AES nejsou "univerzální klíče". Váš prohlížeč věří, že klíč, o němž Verisign prohlašuje, že je důvěryhodný, je opravdu důvěryhodný. Atakdále. Ostatně, věříte své bance, že vaším jménem nebude někde nakupovat?
U OpenID je situace analogická: Věříte, že když Verisign (Seznam, MyOpenID, …) potvrdí, že uživatel XYZ je opravdu XYZ, tak že nemá důvod podvádět, a zároveň věříte, že nemá důvod falšovat vaše přihlášení.
Pokud nevěříte, tak vám nepomůže ani vlastní OpenID provider na vlastním serveru na páteřní síti – co když je v systému bezpečnostní díra, o které nevíte, a někdo tak může získat kontrolu nad vaším strojem? A podobných analogických "oprávněných strachů" bych mohl jmenovat víc.
Zkrátka: Musíte aspoň někomu důvěřovat, nebo alespoň odlišovat někoho, komu věříte víc, a někoho, komu věříte míň, a podle toho jim svěřovat svá data. Paranoia je v rozumné míře oprávněná, pokud ovšem rozumnou míru překročí, tak zjistíte, že nemůžete věřit nikomu a že vám pomůže už jen odpojit se od internetu, spát v alobalové krychli a jíst jódové tablety.
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.
Otázka důvěryhodnosti poskytovatele OpenID identity je stejná jako otázka důvěryhodnosti vašeho providera, vašeho hostingu, správce vašeho serveru, otázka důvěryhodnosti Seznamu, PayPalu, Google, brány pro kreditní karty apod. Až pominou rozjitřené vášně, tak lidé zjistí, že s bezpečností OpenID to je stejné jako s jinými nástroji: Stačí u toho přemýšlet. A stejně jako nezakládám e-mailovou firemní schránku u nějakého Joudy, stejně jako nehostuju servery s důležitými informacemi "u kamaráda v ložnici", stejně jako nepoužívám připojení, co za mne blokuje obsah, který bych neměl vidět, a stejně jako neposílám peníze potomkům nigerijského krále, tak si vyberu i důvěryhodného poskytovatele OpenID, který se nebude přihlašovat "za mne".
"V pripade, ze ale hodlate komunikovat se zakaznikem a pomoci vaseho systemu si sdelovat duverne informace obchodniho charakteru, tak je OpenID zcela nevhodne." – 1. Proč? 2. Je tedy něco vhodného?
"OpenID ne, kde se pracuje s duvernymi informacemi." – Otázkou je míra důvěrnosti těch informací. Jak jsem už říkal: Do banky bych to nepoužil, na e-shop klidně (já svému OpenID poskytovateli věřím). Rozhodně bych tu viděl použití OpenID méně problematické než použití HTTP autentifikace Plain (nebo dokonce jméno+heslo poslané přes nešifrované http).
Mimochodem, tam, kde se pracuje s Opravdu Důvěrnými Informacemi, se hlavně nepracuje s ničím jiným a přístup tam nezískává kdejaký jouda, takže to je zcela jiná kategorie, mimo záběr tohoto článku.
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?
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.
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…
Krom toho musite vytvorit i seznam vsech certifikatu OpenID provideru, jinak se muze stat ze budete komunikovat s uplne nekym jinym.
Já bych řekl, že jako server nic takového dělat nemusíte. Nebo snad "jako server" máte whitelist "důvěryhodných mailových služeb", které mohou zadat uživatelé jako svůj kontakt?
Situace je analogická: Mail můžete mít u důvěryhodného poskytovatele, stejně jako OpenID identitu. Můžete ho mít u poskytovatele pofidérního, OpenID identitu taky. Mail můžete mít na vlastním serveru, ostatně OpenID rovněž. No a konečně můžete použít pro registraci Mailinator nebo jiné podobné "veřejné temporary" maily – což by byl zhruba ekvivalent onoho "alwaysok".
Vy jako server samosebou víte, že to, jestli má váš uživatel nedůvěryhodného správce mailu (nedůvěryhodného poskytovatele OpenID) nijak neovlivníte. Přesto nabídnete např. "zaslání hesla mailem", aniž byste dělal whitelist důvěryhodných mailových služeb, kde uživatelům nečtou poštu. To je to samé a je to založené na předpokladu, že useři volí důvěryhodné maily. Jenže mezi uživateli jsou BFU co použijí klidně kamarádův mail a na jeho adresu si založí vlastní účet všude možně. Důsledky si domyslete sám. :) Přesto tahle eventualita nikoho netrápí a nikdo neprohlašuje mail za nebezpečný a naprostá většina serverů jej klidně používá k registraci.
Jediný důvod, kde jsem ochoten do jisté míry uznat tento argument, je "novost služby", kdy rozumní uživatelé (to není BFU) ještě nevědí, které autority jsou důvěryhodné a které míň. Tedy podobná situace jako na konci 90. let s mailem. Ale vývoj nebude ten, že se "nějak zlepší" mechanismus OpenID, ale že lidé zjistí, který poskytovatel je bezpečný a důvěryhodný a který ne. Jako se to naučili u mailů.
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.
"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í).
Netvrdite, jenom spousta lidi si mysli, ze certifikatem je zarucena pravost providera. Takze na to upozornuju, ze to tak neni.