Az authentikáció kérdése elég érdekes manapság, mivel már nem csak a “bekérem a felhasználónevet, jelszót” változatot kell jellemzően megvalósítani, mikor hitelesíteni akarjuk a felhasználó személyét. Az OpenID és oAuth protokollok úgy biztosítanak hitelesítést, hogy az oldal nem tudja meg a felhasználó jelszavát, az egy harmadik félnél van. A dolog nálam egyéb okokból is aktuális, de az OpenID azért is jöhet a képbe, mert most már mind a három nagy támogatja: a Yahoo!, a Microsoft és a Google is.
Kimazsolázni a különbséget a két megoldás között nem feltétlenül könnyű, én is csak most ismerkedem ezekkel a protokollokkal (ha van tipp, jöhet!), de a lényeg, hogy az OpenID segítségével alapvetően annyit lehet kiszedni a szerverből, hogy sikeres volt-e az authentikáció, vagy nem, míg az oAuth további adatok biztonságos forgalmazását is lehetővé teszi (gondoljunk itt egy API-ra). Mind a két megoldás alapja egy authentikációs szerver, ahol nyilván van tartva a felhasználói azonosítónk és jelszavunk (vagy más formában kínál azonosítási lehetőséget), s ezt a szervert használva léphetünk be különböző oldalakon úgy, hogy közben a céloldal nem fogja megtudni sem az azonosítónkat, sem a jelszavunkat. Hozzáteszem, az OpenID-nak van egy kiegészítése, mely segítségével lehetőség van személyes információkhoz (pl. az azonosító) történő hozzáférésre (akár azok megváltoztatására is), az oAuth keretében pedig magának a protokoll használatának keretében dönthet úgy a szolgáltató, hogy biztosít olyan interfészt, ahogyan ez megtehető. Nyílt protokollokról van szó: ingyenesen használhatóak, és nyílt szabványokra, algoritmusokra épülnek.
Egyik protokollra sem mondanám, hogy egyszerű, mindkettő ide-oda üzengetést tartalmaz, jellemzően a biztonságot szem előtt tartva aláírva valamilyen algoritmussal az üzeneteket. Az OpenID authentikáció kiegészítője az OpenID tulajdonságcsere, ezekkel a doksikkal érdemes kezdeni egy átfogó kép kialakításához, majd mondjuk megnézni egy gyakorlati dokumentációt. Kész kódok is rendelkezésre állnak különböző nyelvekhez, de ehhez már jellemzően érteni kell magát a protokollt, vagy legalábbis a főbb elemeit. Az oAuth-tal történő ismerkedést is az oAuth specifikáció segítségével lehet érdemes kezdeni. Ezután szintén egy gyakorlatibb útmutatót, majd kész kódok nézegetségét tudom ajánlani.
Amit eddig még nem mondtam el, hogy miért is jó nekünk, ha ezekkel megismerkedünk (persze mindenki döntse el maga). Az OpenID kapcsán ha lehetővé tesszük annak használatát oldalunkon, akkor megkönnyíthetjük a felhasználók regisztrációs folyamatát mind fizikailag (pár kattintással túl tudnak lenni rajta – nincsen emailes megerősítés), mind lelkileg (nincs jelszó megadás, és gyors a folyamat). Ez sokat jelenthet, hiszen a felhasználónak megspórolhatunk pár percet – ami nagyon sok, ha azt nézzük, hogy 5 másodpercet sem szoktunk kivárni egy oldal letöltésekor.
Az oAuth akkor jó, hogy olyan webszolgáltatást írunk, mely együtt szeretne működni más szolgáltatásokkal a neten. A régimódi megoldás erre hogy bekérjük a másik szolgáltatás felhasználónevét, jelszavát ha szeretnénk a felhasználó más szolgáltatásnál tárolt adataihoz hozzáférni, ez azonban nem igazán bizalomgerjesztő, hiszen azt le kell tárolnunk: ha hozzánk betörnek, a másik szolgáltatáshoz is nyitott az út, illetve az sem nyugtatja meg a felhasználót, hogy látjuk ezeket az adatait.
Nehany kiegeszito gondolat:
1. Azt fontos tudni meg, hogy sem az OpenID, sem az oAuth nem rendelkezik trust (megbizhatosagi) modellel. Ez az egyik oka, ami miatt a nagy OpenID szolgaltatok, nem fogadnak el OpenID-t a sajat szolgaltatasiknal.
2. Kulfodi felhasznalok eseten olyan 23-30 % (mert adat) valasztja az OpenID-t ha erre modja van (nyilvan ez a szam noni fog). Kb. ugyaennyi felhasznalo nem is lep be az oldalra, ha regisztralnia kell. Magyaroszagon ez a szam nagyon alacsony.
3. Az attribute exchange kiegeszitest nem lehet feltetelezni az szolgaltatoknal (gyakran nincs telepitve, implementalva).
4. Vigyazo szemetek a SAML 2.0/InformationCard megoldasokra vessetek!
5. oAuth csak Web alapu szolgaltatasoknal mukodik, mivel bongeszo kell a kommunikaciohoz, hatterben futo, automatizalt feladatokat nem lehet elvegezni vele.
Ferenc Szalai: Néhány válasz, azzal együtt, hogy majdnem minden pontban egyetértünk.
1. De mi megbízhatunk a nagy szolgáltatókban, legalábbis ezirányban.
2. Ezért kell őket tanítani. Mo-on a fejlesztők nem építik be ezeket a szolgáltatásokat, nem csoda hogy alacsony, ha a felhasználó nem tudja miről van szó.
3. A Google viszont támogatja.
4. Ezt egyelőre a legnagyobbak sem támogatják (vagy igen?)
5. Google azt mondja: “Access tokens are by default long-lived, and can be used any time the web application needs to access a covered service for that user’s data.” – ebből én arra következtetnék, hogy egyszeri authentikáció után az alkalmazásunk szabadon hozzáférhet az adatokhoz. Odáig nem jutottam még el, hogy ki is próbáljam. Persze ez is lehet tök szolgáltatófüggő.
1. Nem az a baj, hogy a nagyokban megbizol, hanem az hogy az alap implementacioban minden jott-ment idp-ben is megbizol. Azaz vagy azt csinalod csak altalad megadott IdP-kben bizol meg vagy elkezdesz blacklisteket epiteni. Ne feledd barki felhuz egy idp-t kb 5 perc alatt. Nem kell hozza cert, X509 infrastukura, kolcsonos bejegyzesek stb. Ezert szeretik, de az ez az egyik hatranya is.
2. Egyetertek. Sajnos, ahol eddig volt ilyen ott teszteltem es az esetek tobbsegeben rosszul, hibasan epitettek be.
3.Igen ez igaz, de hat most google-el akarunk authentikalni vagy mindenkivel? Ertem persze mire celzol
4. De, foleg csak a nagyok: Google, Salesforce stb.
http://blog.pingidentity.com/blog/default/2008/10/29/SaaS-Vendors-Select-PingFederate-for-SSO
Az ‘igazi’, uzleti SaaS szolgaltatasok erre fognak epulni hamarosan, mert ott nagyobb trust kell es foleg szervezetek kozott.
Nyilvan a kozossegi, nagy mennyisegu felhasznalok szamara adott oldalakon valoszinuleg az OpenID vagy ahhoz hasonlo dolog lesz nyero. De ha megnezi valaki az OpenID fejlesztei iranyokat annak az lesz a vege, hogy ujra feltalalljak a SAML 2.0.
De nyilvan en elfogult vagyok
5. En ugy emlekszem a long-lived naluk par orat jelent es valoban szolgaltatas fuggo. Ez mar keves lehet arra, hogy napi egy backend cron eljarast futtatgassal. Arrol nem is beszelve, hogy a oAuth nem erre lett kitatalva, azaz nem massziv adattranszferre.
Én látok még egy jelentős különbséget, ami már a nevükben is megjelenik: az OpenID célja az elosztott identitás management. Tehát hozz létre egy felhasználót bárhol, majd használhatod azt minden site-on.
Az oAuth ezzel szemben az authentikációra fókszál, és nem foglalkozik azzal, hogy ki az alanya az authentikációnak. Sokkal inkább a szerver-szerver kommunikáción van a hangsúly, mint az OpenID esetében. Ezen felül tartalmaz egy kérés aláírási eljárást, amivel publikus kulcs csere után a szerverek a háttérben, a felhsználó tudta nélkül is tudnak kommunikálni (http://code.google.com/apis/accounts/docs/OAuth.html#SigningOAuth). Ezt egyébként az OpenSocial is használja.
Másik szemszögből: az OpenID egymástól “távoli” rendszerekben gondolkodik, akik egyáltalán nem ismerik egymást, de egy általános bizalom alapján szeretnék a többiek felhasználóit beengedni. Az oAuth ezzel szemben “közeli” rendszereknek készült, ahol a rendszerek előzőleg “megismerkedtek” egymással. Például több partner vállalat rendszerei közötti kapcsolattartást segítheti.
A fentiek alapján elképzelhető a két megoldás együttes használata is: egy szolgáltatáshalmaz (mint például a Google szolgáltatásai, vagy egy opensocial container és a gadgetek) részei egymás között oAuth-ot használnak, de amikor az oAuth a felhasználó ellenőrzéshez ér (a dokumentációban a 4.-es lépés), akkor OpenID-t is elfogad, nem csak felhasználónevet/jelszót (rsa id-t, újlenyomat leolvasót, postagalambot, stb)
Természetesen ujjlenyomat-olvasót akartam írni… :/