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

Zdroják » Různé » OpenID vs OAuth: bitva, která se nekoná

OpenID vs OAuth: bitva, která se nekoná

Články Různé

V souvislosti s blížícím se spuštěním služby MojeID od CZ.NIC se opět hovoří o protokolu OpenID. Diskuse jsou bouřlivé a argumenty vášnivé. Na Zdrojáku jsme o OpenID a dalších metodách měli před časem celý seriál; dnes se k němu vrátíme, a to článkem o velmi časté chybě, která se v těchto diskusích objevuje.

Nálepky:

Na úvod je nezbytné uvést jednu věc: V článku nebude řeč o tom, jestli OpenID „umírá“, jestli „se nikdy neprosadil“ apod. – takové dohady nechme na Lupu či Roota, kde už, minimálně v komentářích, probíhají. A padají tam argumenty od zasvěcených a minimálně zváženíhodných až po naprosto liché. Čas od času se objeví i komentář od „odborníka“, který píše: „OpenID je mrtvý, měli by použít OAuth, ten jede!

A protože tenhle komentář se opakuje častěji než by bylo zdrávo, podíváme se na obě technologie, srovnáme si jejich schopnosti, funkci a (především) koncepci, zaměření a určení. Řekneme si, pro co je která technologie použitelná a jakým způsobem. Po přečtení článku si už dokážete sami odpovědět, jestli „by měli místo OpenID použít OAuth“…

OpenID

OpenID (viz články na Zdrojáku a seriál o autentizačních metodách) je technologie, jejímž cílem je vytvořit univerzální otevřený decentralizovaný systém ověřování identity. Co to znamená?

Univerzální

OpenID je teoreticky možno použít kdekoli, v jakékoli službě, v jakémkoli webu, kde potřebujete „přihlásit uživatele“. Všude tam, kde dnes existuje „přihlášení jménem a heslem“, může být nasazeno OpenID. Uživatel se může přihlásit pomocí svojí OpenID identity; OpenID protokol definuje, jaké kroky má klient, tedy stránka, kam se přihlašuje, udělat, jak má předat požadavek identifikační autoritě (v terminologii OpenID je to poskytovatel), co má poskytovatel s požadavkem udělat a jakým způsobem má dát vědět zpět klientovi, že daný uživatel je opravdu tím, za koho se přihlašuje.

Aby celá věc byla opravdu univerzální, zahrnuje OpenID protokol několik úrovní zabezpečení, takže citlivé operace lze např. podmínit tím, že klient bude po poskytovateli vyžadovat, aby uživatele ověřil pomocí více metod (např. pomocí hesla a pomocí PIN kódu zaslaného mailem). Klient může dokonce požadovat, aby alespoň jedna z použitých metod byla „ne-online“, tedy např. autorizační SMS nebo pomocí HW modulu s klíčem.

OpenID protokol je proto velmi komplexní. Definuje vše, od toho, jak má vypadat požadavek a jak má být předán, přes položky, které může uživatel vyplnit a klient požadovat, až po podmínky, za jakých poskytovatel tyto informace předá a kdy si má vyžádat svolení od uživatele.

„Nechci, aby MojeID posílalo všechny moje údaje při každém přihlášení komukoliv.“ Tak tomu není, uživatel při povolování přístupu vidí, jaké informace stránka požaduje, které z nich považuje za nezbytné, a může se rozhodnout, které chce dát a které ne. Pokud nechce dát žádné, tak se nic nepošle. Klienti mohou mít tendenci vyžadovat víc, než opravdu potřebují – pak se ale nesmí divit, když jim uživatelé nebudou chtít tyto informace poskytnout.

Otevřený

Protokol OpenID je od začátku koncipovaný jako otevřený – tedy za jeho použití nemusíte platit, jeho specifikace je plně k dispozici a není zatížená licenčně ani nepatří nějaké firmě. Což je na druhou stranu problémem ve chvíli, kdy si někteří začnou při implementace specifikaci přiohýbat, vytvoří pak „něco na téma OpenID“, ovšem kompatibilita s ostatními je pak docela problematická (analogie lze v IT nalézt skoro na každém kroku), což nepřispívá pověsti celé technologie.

Decentralizovaný

Tento rys OpenID je naplněn možností zvolit si poskytovatele OpenID identity dle vlastního přání – tedy vybrat si takového, který je mi sympatický, který nabízí funkce, jež mě zajímají (např. možnost více sad „personálních informací“ u jednoho účtu) či který je důvěryhodný (banky, certifikační autority, …) Ostatně je možné být i poskytovatelem identity sám sobě.

Ověření identity

Ověření identity je základní funkce OpenID. Znamená to, že OpenID nabízí mechanismus, jakým lze zjistit, že uživatel s identifikací A je tentýž, který se přihlásil minulý týden s identifikací A. Že to není někdo jiný. To, co bude ve skutečnosti o uživateli A vědět, záleží jen na uživateli samotném a na providerovi.

Princip fungování OpenID je tedy takový, že uživatel si vytvoří u poskytovatele identit svůj záznam. Tento záznam má přiřazen nějaký identifikátor, kterým se uživatel hlásí ke stránkám, jež OpenID podporují. Aby celý systém fungoval tak, jak má, je zapotřebí mít širokou škálu poskytovatelů, kteří implementují OpenID protokol opravdu dle specifikace.

OAuth

Protokol OAuth (viz článek o OAuth na Zdrojáku) nabízí jednotnou metodu autentizace uživatelů, přistupujících k API webové služby, a to pro webové i desktopové aplikace. OAuth je jednoduchá specifikace, která popisuje způsob, jakým má aplikace, která chce přistupovat k API, požádat o autentizační informace.

API

Nejrůznější webové služby, především sociální sítě, nabízejí API pro přístup ke svým funkcím, takže vývojáři mohou tvořit aplikace, které jsou na těchto funkcích založeny nebo je mohou využít. Lze tak vytvářet aplikace, které mohou publikovat přes Twitter, přes Facebook, přistupovat k fotografiím v albu apod. Je tedy logické, že přístup k podobným funkcím musí být ověřen uživatelským souhlasem.

Ověření uživatelů

OAuth má jediný úkol: Zajistit, že aplikace třetí strany může přistupovat k důvěrným funkcím přes API určité služby, aniž by musel uživatel dávat svoje přístupové údaje aplikaci třetí strany – v takovém případě hrozí vždy riziko zneužití. OAuth toto riziko obchází tím, že přihlášení probíhá pouze na stránce dané služby a aplikace třetí strany obdrží pouze unikátní klíč, pomocí něhož může podepsat své API požadavky.

Proces ověření

Ověření uživatele – protokol OAuth

V praxi to probíhá tak, že aplikace třetí strany chce použít u konkrétní služby (uvedeme si jako příklad Twitter) některou funkci, která vyžaduje autentizaci. Požádá tedy nejprve Twitter o token. Dostane jej a spolu s ním přesměruje uživatele na stránky Twitteru. Na té stránce se uživatel přihlásí svým twitterovým účtem a povolí dané aplikaci třetí strany přístup k funkcím. Pak je vrácen zpět na stránky dané aplikace spolu s dalším kódem. Nakonec aplikace pomocí tohoto kódu požádá o přístupový klíč. S tímto klíčem už může přistupovat k důvěrným funkcím API.

Shrnutí

Mezi OpenID a OAuth jsou, jak jste viděli, zásadní rozdíly. Shrňme si je v tabulce:

OpenID vs OAuth
Rys OpenID OAuth
Rozsah Definuje komunikační protokol, výměnu informací, rozsah informací, obsahuje i několik úrovní autentizace Definuje jen komunikační protokol pro autentizaci; veškeré další zjišťování údajů musí proběhnout přes proprietární API té které služby
Architektura Distribuovaný autentizační systém, kde jsou uživatelské účty nezávislé na službách, které je využívají Zajištění autentizace uživatelů konkrétní služby
Problém, který řeší Obecné ověření uživatele; poskytnutí některých informací o něm; zabezpečení přihlašování Ověření uživatele kvůli přístupu k důvěrným funkcím API webových služeb.
Topologie „Uživatelsko-centrická“ (důraz je kladen na identitu uživatele) „Službo-centrická“ (důraz je kladen na samotný fakt ověření)
Uživatelský účet Může být u libovolného poskytovatele; lze jej použít v různých službách Uživatel musí být nejprve zaregistrován u dané služby

Samosebou existují způsoby, jak oba přístupy zkombinovat. Důležité je si uvědomit, že každá technologie řeší naprosto odlišný problém, jiným způsobem a v jiném rozsahu, tudíž nejsou ani vzdáleně zaměnitelné. OAuth je malá specifikace, jejímž cílem je zajistit „podepsání“ požadavků při volání citlivých funkcí API. OpenID je komplexní technologie distribuované správy uživatelských účtů; kromě samotného přihlášení řeší i výměnu informací o uživateli a další věci, spojené se zabezpečením.

OAuth je malý a jednoduchý, za dvě hodiny jsem ho měl rozběhaný, ale OpenID mi trval celý den.

A pokud to chcete ještě názorněji, tak: Pomocí OAuth řešíme „přihlášení k Twitteru jako uživatel XYZ“, pomocí OpenID řešíme „přihlášení uživatelů k naší službě s jejich vlastním ID“. Ano, za jistých podmínek lze vytvořit službu, k níž bude možné se přihlásit „pomocí twitterového účtu“ a získat informace (pomocí volání nějakých dalších funkcí via API), aniž by ta služba nějak s Twitterem souvisela (dtto s Facebookem), ale zkuste se zamyslet: Jaký by to mělo smysl? Jaký by mělo smysl omezit přihlašování uživatelů k vaší službě pouze na množinu těch, kteří u toho serveru mají účet, pokud by vaše služba nebyla nadstavbou nad daným serverem?

Závěr

V diskusích o OpenID (a MojeID) není vyřčena spousta věcí, např. to, že korektní implementace na straně klienta není omezena na použití MojeID – stačí, když klient bude s protokolem OpenID pracovat tak, jak má, a nebude vymýšlet proprietární hacky typu vyhodíme vše, co nebude mojeid. Správné použití je „požádat o ověřenou identitu“, a je jedno, jestli má uživatel účet u mojeID nebo u Verisign nebo jestli mu jeho OpenID identitu ověří jeho banka.

Ale tento článek nebyl věnován neznalostem diskutujících o podstatě věci, byl věnován jednomu mýtu, který by se dal vyjádřit výše zmíněným komentářem: „Proč implementovali mrtvé OpenID, proč nepoužili OAuth?!“ No proto, že by pak nevzniklo „ověření identity“, ale „nástroj pro přihlášení k API CZ.NIC“.

Komentáře

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

Bravo autore!

Konecne nekdo jasne a hlavne strucne vysvetlil tem „odbornikum“, jak se veci maji. Doufejme, ze se probudili ze snu …

ondra.novacisko.cz

U OpenID vždycky zůstane jedna jediná informace, kterou nelze skrýt před service providerem.

A to je vlastní identifikátor, který jednoznačne identifikuje uživatele. Tak jak je OpenID navrženo ani neumožňuje jiné řešení. Podobné historické omyly zname z minulosti, například dodnes zastaralý a stále masivě používaný SMTP protokol prostě nelze technologicky vylepšit tak, aby bránil Spamu. A našlo by se toho víc.

Mám řešení, ale nechci dělat spammera na fórech :-)

Mordae

Myslis napric sluzbami? To je problem, protoze pak se daji spojit aktivity na vice sluzbach a jedna cast anonymity je v trapu. Jedine, ze by OpenID melo jiny identifikator pro kazdou sluzbu a drzela mapovani na fyzicke ucty. A nebo mit vice identit.

Na druhou stranu, uplna anynymita stejne neni realna a pri nejlepsim jsi alespon podezrely, protoze pouzivas anonymizacni technologie…

ondra.novacisko.cz

No mě mrzí, že OpenID se nedrželo osvědčeného a léty prověřeného formátu: e-mailová forma.

Netvrdím, že ID: franta@seznam.cz musí mít e-mail na seznamu, ale dalo by se to dobře použít i jako identifikace. „Franta ze seznamu“. Seznam ověří frantu.

Dneska se stejně na spoustě služeb používá e-mail proto, aby se jednak dalo ověřit, že uživatel má aspoň schránku a pak, aby si uživatel nemusel vymýšlet identifikátor, kde existuje reálné nebezpečí, že bude duplicitní. E-mail duplicitní není.

Heslo se registrací na e-mail nevyřeší, a navíc stoupá nebezpečí, že lidi tam budou rvát hesla do svých mailboxů.

Chránit svou identitu lze tak, že service providerovi řeknu, že jsem @seznam.cz a seznamu pak řeknu, že jsem franta a mám heslo: anežka. Poskytovatel identity pak vytvoří identifikátor který bude unikátní v rámci kombinace Uživatel-SP-IdP – a klidně to může zahashovat, aby to nebylo čitelné. Service provider tedy bude umět ověřit uživatele při každém vstupu, spárovat ho s tabulkou uživatelů, kteří přistupují do jeho informačního systému a přitom nebude mít šanci zjistit, že na vedlejší službě, kterou taky provozujem, se tentýž uživatel také přihlašuje. (jedna služba je diskuzák a druhá pornostránky jako příklad).

ondra.novacisko.cz

URL není formát určen pro identitu uživalů. URL je formát určen pro identifikaci zdrojů.

„ovšem musí to podporovat poskytovatel“

Je přesně to co OpenID zabije. Oni toho poskytovatelé a provideři musí podporovat hodně, aby se dalo OpenID vůbec provozovat.

Mimochodem, jak se vám líbí OpenID od Seznamu? Hrůza co? A to je ještě dobrý. Vysvětlovat lidem co je OpenID je šílenost. Nicméně dát jim do login stránky okénko s popiskem „sem napiště váš e-mail“ pochopí každej.

ondra.novacisko.cz

„Informace o uživateli“ jsou zdroj.

Hezký úlet.

Mimochodem, i v samotném url je jméno uživatele před zavináčem:
http://franta@example.com/

No prostě tady udělali soudruzi z NDR chybu. Toť můj názor.

ondra.novacisko.cz

Jenže já nejsem BFU. Mě zase vrtá hlavou proč Root nemá OpenID…

tedy vlastně já to vím. Vím proč ho nemají ani jiné weby, třeba Alza, czc, lopuch, facebook, idnes, aktualně :-)

Protože OpenID je dinosaurus.

ondra.novacisko.cz

Abych odpověděl na otázku. ondra.novacisko.cz je jedna z možných ID a když si přečtete specifikaci, tak zjistíte, že moc není doporučovaná.

správně by to mělo být s http na začátku. a to neuvažuju ty varianty s rovnítkem na začátku :-)

Ale klidně bych měl ondra@novacisko.cz a vizitku na http://ondra@novacisko.cz/ proč ne?

Nebo byste radši šel cestou, že by i e-mail byl ve formě ondra.novacisko.cz?

Proč mít jednotnou identifikaci ve více formátech? Co je to za jednotnou identifikaci?

„Nicméně dát jim do login stránky okénko s popiskem „sem napiště váš e-mail“ pochopí každej.“
To sice pochopí, jenže se najde spousta lidí, co tam bude cpát „obyčejný“ e-mail a ne identifikátor nějaké autentizační služby, který vypadá jako e-mail. A pak se budou strašně divit, že se nemůžou přihlásit – vždyť tam přece zadali svůj e-mail, jak bylo napsáno na formuláři.

ondra.novacisko.cz

„Heslo se registrací na e-mail nevyřeší, a navíc stoupá nebezpečí, že lidi tam budou rvát hesla do svých mailboxů.“

http://www.root.cz/zpravicky/vetsina-uzivatelu-ma-stejne-heslo-na-e-mailu-a-socialnich-sitich/

(login do facebooku = e-mail)
(e-mail + heslo k e-mailu = vykrádačka e-mailu)

heptau

To se mi zda naopak jako vyhoda. Kazdy OpenID provider si to muze udelat jinak, takze kdyz nekde ziskam hromadu OpenID URI, tak je nemuzu pouzit pro rozesilani spamu. Ale pokud OpenID provider chce, muze si udelat URI temer jako adresu treba uzivatel.at.do­mena.cz

Jestli se nemylim, tak Seznam udell svym uzivatelum OpenID ve tvaru uzivatel.id.sez­nam.cz pripadne uzivatel.id.do­mena.cz (pro ostani domeny).

Navic se mi zda (podle toho co jsem videl na Wiipedii), ze OpenID URI nemusi byt jednoznacne, takze by teoreticky mohlo stacit jako URI domena.cz a sve uzivatelske jmeno si uz clovek vyplni primo na serveru OpenID providera.

heptau

Podle Wikipedie je u nekterych OpenID provideru mozne zadavat identifikator bez username (Yahoo!, MyOpenID, VeriSign…), z cehoz soudim ze pro zachovani jednoznacnosti uzivatele musi OpenID provider vracet serveru nejakou jednoznacny identifikator. Ovsem vzhledem k tomu ze ten identifikator vraci OpenID provider, tak by nemel byt velky problem aby vracel kazdemu serveru jiny (a tudiz by nebylo mozne uzivatele na ruznych serverech spojit) a nebo by mohl vracet i pro jednoho uzivatele ruzne identifikatory/pro­fily (jednou vystupuji za sebe, jednou za firmu…) Samozrejme ze pro ten jeden server server je ten muj identifikator/pro­fil stale jednoznacne identifikovatelny, coz ale je ucel a ne chyba.

benzin

Takze pri pouziti OpenID mate 2x vetsi riziko jak napadani tak nedostupnosti sluzby. Pokud spadne (nebo proste ukonci cinost) OpenID provider skonci i vsechny vase ucty na vsech sluzbach kam ste pomoci tohoto uctu pristupoval. A to same plati pro pripad ze nekdo uspesne napadne vase OpenID providera.

P.S.: U OAuth neni potreba mit ucet u dane sluzby, sluzbe totiz uplne staci informace o uctu, ktere dostane od OAuth providera na to aby mohl urcit ze ted komunikuje se stejnym uctem jako komunikovala pred peti dny. Coz je hlavni smyslem technto identifikacnich sluzeb. Tam kde mi ani tak nejde o bespecnost dat, jako o to aby uzivatel videl sve data jsou obe sluzby pouzitelne.

P.P.S.: Napr. google gadgets, podporuji pouze OAuth.

lopata

Otázka proč udělat přihlašování na nějaký web pomocí OAuth facebooku? Jednoduše proto, protože na facebooku je dnes většina a svůj účet zná, ale o OpenID neví kromě pár tech fanoušků nikdo nic i když třeba už má více OpenID identit. Na a proč pak taky nevyužít nějaké to API a nějak do našeho webu ten facebook trochu natlačit?

Autor článku to vidí strašně akademicky a „podle specifikace“, ale už mnohokrát to právě z technologiemi, protokoly dopadlo tak, jak by vlastně vůbec nemělo. Proto bych spíš souhlasil s článkem Adama Štraucha.

peep

za zmínku stojí pročíst si toto:

http://code.google.com/intl/cs/apis/accounts/docs/OpenID.html#oauth

BTW: moje OpenID je: http://openid.swekey.com/filip@mxd.cz – krásná a levná ukázka HW autentizace

lopata

Názor proti názoru, až praxe může ukázat, jestli to má cenu nebo ne. Vaše argumenty jsou pořád technické (na FB jsem nikdy nebyl, takže o problémech na něm nemohu soudit), kdežto ty mé spíše sociologické.

Viděl jste např. http://www.trop.cz/login, takhle bych řekl že má být uděláno přihlášení na českou službu přívětivě a univerzálně pro všechny uživatele, které by služba/web mohl zajímat. A asi vůbec ne náhodou je „první“ seznam a vůbec nezáleží na tom, jestli seznam používá OpenID/OAuth – vámi popsaný „centrální“ princip platí naprosto stejně. A poslední někde vzadu máme obecné univerzální OpenID.

hm

Fakt takhle, podle TROP.CZ?
########
XML Parsing Error: undefined entity
Location: http://www.trop.cz/
Line Number 41, Column 25:  
————————^
########
No, tedy, já teď nějak nevím, ale takhle snad raději opravdu ne. :-|

hm

Ještě tam byl řádek s nějakými tagy, který tento web ovšem zahodil.

dfasdf

V clanku bylo par nepresnosti, ale jinak je to hezky napsane a spouste lidi to pomuze, takze diky za ne :-)

Prihlasovani pomoci facebooku/goo­gle/twitteru vidim jako rozumnou vec – prvni prihlaseni provede automatickou registraci, vytahne se i emailova adresa a predvyplni prezdivka. Jasny krok vstric uzivatelske privetivosti.

Kdyz vypadne facebook je to to stejne jako kdyz vypadne konkretni poskytovatel openid, to stejne kdyz me nekdo blokne (na facebooku se to stava mnohem casteji, to je pravda), porad ale mame vytvoreneho uzivatele v systemu, staci mu vygenerovat a poslat nove heslo.

Kazdy problem ma sve reseni a podpora prihlasovani pomoci FB za to rozhodne stoji.

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.