Megjegyzések: Aktuális: OpenID, oAuth

mrbig

mrbig — Fri, 14 Nov 2008 10:13:35 +0000

Természetesen ujjlenyomat-olvasót akartam írni… :/

mrbig

mrbig — Fri, 14 Nov 2008 09:54:18 +0000

É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)

Szalai Ferenc

Szalai Ferenc — Thu, 30 Oct 2008 17:20:46 +0000

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.

Bártházi András

Bártházi András — Thu, 30 Oct 2008 16:36:49 +0000

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ő.

Ferenc Szalai

Ferenc Szalai — Thu, 30 Oct 2008 13:01:24 +0000

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.