ugrás a tartalomhoz

OAuth hogyan?

inf3rno · 2013. Aug. 11. (V), 14.21
Sziasztok!

Érdekelne, hogy van e valakinek tapasztalata OAuth-al, esetleg az elvével tisztában van e? Valahogy képtelen vagyok felfogni, hogy miért biztonságosabb, mint egy sima session cookie-s munkamenet...
 
1

Közben megvilágosodtam, hogy

inf3rno · 2013. Aug. 11. (V), 14.39
Közben megvilágosodtam, hogy nagyjából hogy mehet ez az egész:
-> minden egyes kliens kap egy api key-t, amihez tartozik egy secret key, ezzel fog hash-t generálni, nevezhetjük nyugodtan salt-nak is
-> a kérésből a secret key segítségével létrehoz egy signature-t
-> a kéréssel együtt elküldi a signature-t és az api key-t
-> a szerver az api key alapján kikeresi a secret key-t, ő is létrehoz egy signature-t a kérés alapján, és összehasonlítja a kliens által küldöttel
-> ha stimmel a signature, akkor elfogadja a kérést, ha nem, akkor visszadobja

-> az api key-hez lehet esetleg jogokat hozzárendelni


Ha ez tényleg így megy, akkor lehet, hogy problémás, mert azt olvastam, hogy nem szabad ugyanazt a salt-ot többször felhasználni, minden hash-hez újat kell generálni, mondjuk azt nem írták le, hogy miért...
2

Az OAuth egy olyan protokoll,

MadBence · 2013. Aug. 11. (V), 14.43
Az OAuth egy olyan protokoll, ami azonosítást biztosít fb/twitter/google/github/stb segítségével úgy, hogy az oldalon nem kell szenzitív adatokat megadni. Nem tudom hogy jön ide a session cookie :)

Lényegében úgy működik, hogy:
  • A Júzer elmegy az oldaladra.
  • Átirányítod az OAuth providerhez (az alkalmazás regisztrált azonosítójával)
  • Ő rábök arra, hogy igen, engedi a hozzáférést az adataihoz
  • Az OAuth provider átirányít az eredeti oldalra, egy tokennel együtt.
  • A tokent felhasználva igényelni tudsz egy access tokent (token + app secret összekombinálásával), amivel ténylegesen hozzáférhetsz a felhasználó adataihoz az API-n keresztül.
3

Oké, így már világos.

inf3rno · 2013. Aug. 11. (V), 15.35
Oké, így már világos.

Azonosítási módokat nézek, az a kínom, hogy nem tudom, hogy az authorizationt hogy érdemes megcsinálni egy REST service esetében. Mindenhol azt írják, hogy a session cookie elhelyezése nem jó, mert az alkalmazás állapotát REST esetében a kliensnek kell tárolni, nem a szervernek. Szóval a bejelentkezett állapotot is a kliensen kéne tárolni. Én ezzel nem teljesen értek egyet. Alapból ez a REST service is olyan, hogy bejelentkezés nélkül nem lehet használni benne semmit. Egyelőre teljes a káosz...
4

Idézet a wikipédiáról: A

janez · 2013. Aug. 11. (V), 21.42
Idézet a wikipédiáról:
A kliens-szerver kommunikáció tovább korlátozott az által, hogy a szerveren nem tárolják a kliens állapotát a kérések között. Minden egyes kérés bármelyik klienstől tartalmazza az összes szükséges információt a kérés kiszolgálásához, és minden állapotot a kliens tárol. A szerver lehet állapottartó; ez a korlátozás csupán azt követeli meg, hogy a szerver oldali erőforrás-állapotok URL által címezhetőek legyenek. ...


Itt kiemeli hogy a szerver lehet állapottartó, mindössze egy kérésen belül az összes információnak rendelkezésre kell állnia a kiszolgáláshoz.
Nem szép megoldás, de a session key a get-ben elviekben kielégíti ezt a feltételt. Továbbá nyújt valami védelmet, hogy a Rest-et SSL-el szokták kombinálni.

Amúgy a megoldásod, attól függ mit szeretnél.
Én kezdetben csak egy sima API key-et adtam az admin felületen, amivel hozzá fértek az API-hoz. Egy ügyfélnek lehetett több is.
Később próbálkoztam API key + TOTP (Time based One Time Password) megoldásokkal és ott az OAUTH. Attól függ kinek szánod, zárt vagy nyílt kör, stb.
5

Nem szép megoldás, de a

MadBence · 2013. Aug. 11. (V), 22.21
Nem szép megoldás, de a session key a get-ben elviekben kielégíti ezt a feltételt. Továbbá nyújt valami védelmet, hogy a Rest-et SSL-el szokták kombinálni.

Ez abszolút kivitelezhető (és elfogadott) szcenárió. Facebook API-t pl így lehet használni (egy &access_token fieldet oda kell csapni a kérés végére, más szolgáltatásoknál valamilyen HTTP fejlécet, igaziból mindegy)

Nem teljesen értem mi a probléma azzal, hogy hol tároljuk az állapotot. A szerver oldali állapottárolás az lenne, hogy:
  1. A kliens kap egy munkamenetazonosítót az API endpointtól
  2. A kliens(alkalmazás) odaszól az API endpointnak (publikus API-t használ, etc)
  3. A kliens elküldi az autentikációhoz szükséges adatokat, ezt a szerver nyugtázza
  4. A kliens minden változtatás nélkül (a session azonosító marad!) már eléri az autentikációhoz kötött tartalmakat is


Kliens oldali állapottárolás:
  1. A kliens odaszól az API endpointnak (publikus API-t használ, etc)
  2. A kliens elküldi az autentikációhoz szükséges adatokat, ezt a szerver nyugtázza (visszaküldi az access tokent)
  3. A kliens az access tokennel eléri az API endpoint autentikációhoz kötött szolgáltatásait is


Az OAuth az utóbbi forgatókönyvet valósítja meg.
6

Még mindig nem tudom

inf3rno · 2013. Aug. 11. (V), 23.47
Még mindig nem tudom eldönteni, hogy az OAuth megoldás lehet e a problémámra, valószínűleg nem. Van egy REST service, ami adatot szolgáltat, és aminél ellenőrizni kell a jogosultságot. Ehhez vannak kliensek, amik megjelenítik az adatot. Három típusú kliens van, az egyik publikus adatot szolgáltat, a másikhoz szükséges a bejelentkezés, a harmadik meg adminisztrációs, szóval annak még egy fokkal több joga van.

Ha jól értem az OAuth csak arra jó, hogy a felhasználó eldönthesse, hogy ad e hozzáférést a fiókjához külső alkalmazásoknak. Na az én esetemben ez a helyzet nem áll fenn, mivel mindegyik saját oldal. Szóval elméletileg az OAuth nem jó, gyakorlatilag meg mindenhol azt olvasom, hogy a REST service állapotmentes kell, hogy legyen, tehát nem lehet pl session cookie-t vagy munkamenetet használni, mert akkor a szerver fogja kezelni az állapotot és nem a kliens. Nekem egyáltalán nem állt össze a kép, hogy ezt az ellentétet hogy lehet feloldani OAuth-al, pedig stackoverflow-on mindenhol azt írják, hogy szignálni kell a kéréseket, úgy, mint ahogy az OAuth-al csinálják. Maximum azt tudom elképzelni, hogy minden kéréssel felhasználói nevet meg jelszót küldök, de ez meg biztonsági szempontból kalap szar. A vége szerintem az lesz, hogy a REST service-el csináltatok session id-t, hozzácsapom utána minden hozzá érkező kérésnél az url-hez, aztán ennyi. Fel nem tudom fogni, hogy nekem ez miért ne lenne jó...

szerk:

http://stackoverflow.com/a/466806/607033

Közben ez alapján összeállt, hogy szükségtelen az OAuth, ha nem akarok külső alkalmazásoknak jogot adatni a felhasználókkal (már pedig nem akarok). Meg hogy tökéletesen megfelel a queryString-hez vagy header-hez hozzácsapott session id. Még akár cookie-ban is lehetne, csak akkor kellene még egy token, hogy ne lehessen CSRF-el támadni. A queryString-es megoldás kevésbé kesselhető, de azt az adatokra amúgy sem akarok, mert pont hogy azok változnak, maga a kliens meg statikus. Max SQL-re lehetne kesselni...
7

Közben ez alapján összeállt,

janez · 2013. Aug. 13. (K), 00.31
Közben ez alapján összeállt, hogy szükségtelen az OAuth, ha nem akarok külső alkalmazásoknak jogot adatni a felhasználókkal (már pedig nem akarok). Meg hogy tökéletesen megfelel a queryString-hez vagy header-hez hozzácsapott session id. ...


Fentebb én is ezt írtam. :)

Amúgy nem tudom találkoztál-e vele, de nagyon jó kis olvasni való Rest témakörben.
Best Practices for Rest és egy másik kedvencem: RESTful Best Practices.
Az utóbbi sok baklövéstől megvédett.
8

Még nem, köszi, megnézem

inf3rno · 2013. Aug. 13. (K), 13.05
Még nem, köszi, megnézem őket!
9

Azt meg tudod mondani, miért

Hidvégi Gábor · 2013. Aug. 13. (K), 16.04
Azt meg tudod mondani, miért akarod magad a REST által felállított keretek közé kényszeríteni?
10

Persze, szeretek az ajánlások

inf3rno · 2013. Aug. 13. (K), 20.03
Persze, szeretek az ajánlások szerint fejleszteni.
11

Csak azért vetődött fel

Hidvégi Gábor · 2013. Aug. 13. (K), 20.38
Csak azért vetődött fel bennem, mert ez nem az első alkalom, hogy a REST-ről és az azonosításról kérdezel alapvetőt. Nem lehet, hogy a REST-et nem a te alkalmazásodnak találták ki? Miért mások elvárásainak akarsz megfelelni? Miért úgy táncolsz, ahogy mások fütyülnek? Miért nem veszed a kezedbe te a szálakat?
12

Talán mert akkor nem írhatom

inf3rno · 2013. Aug. 13. (K), 22.03
Talán mert akkor nem írhatom le, hogy fejlesztettem REST service-t.

A szabványokat meg ajánlásokat nem véletlenül találják ki, ezek általában jól bevált dolgok, és érdemesebb ismerni őket, mint bármelyik egyedi rendszert.
13

Ez igaz, csak így önként

Hidvégi Gábor · 2013. Aug. 14. (Sze), 10.47
Ez igaz, csak így önként hajtod kalodába a fejed. Akik maradandót alkottak eddig, azok mindig túlléptek az addigi koncepciókon, és valami újjal álltak elő vagy új irányba mentek, gondolj csak Zsákos Bilbóra. Vagy: "És mégis rozoga Föld"
14

Hát én nem programozásban

inf3rno · 2013. Aug. 14. (Sze), 14.05
Hát én nem programozásban akarom megváltani a világot, hanem rákkutatásban, majd ott használom a kreativitásom... :D
21

Simán leírhatod, a REST

tgr · 2013. Aug. 15. (Cs), 18.16
Simán leírhatod, a REST előírások nagyrészét figyelmen kívül hagyni és a végeredményt REST service-nek nevezni mára iparági standard :-)

Egyébként némi joggal, az eredeti REST nagyon be van korlátozva, CRUD jellegű API-khoz nagyon jó, más jellegűekhez (pl. kereséscentrikus) legalábbis kényelmetlen.
15

Szerintem a REST egy nagyon

Joó Ádám · 2013. Aug. 14. (Sze), 17.16
Szerintem a REST egy nagyon általános ajánlás, amit a HTTP, mint az ajánlás egy megvalósítása önmaga ki is kényszerít, ezért nem értem, hogy inf3rno miért pörög rajta ennyit.

Például hogy miért nem jó neki a sütiben tárolt munkamenet-azonosító. A REST által használt session egy protokoll szintű fogalom, nem azonos egy webalkalmazás által használt alkalmazásszintű munkamenettel. Utóbbi ugyanúgy csak egy összetevője az alkalmazás állapotának, mint bármilyen tartalom, amit kezel, és nyilvánvalóan egy állapotmentes alkalmazás teljesen haszontalan.

A fentiek fényében a RESTful service a legtöbb esetben egy pontatlanul használt név azokra a szolgáltatásokra, amik HTTP-t használnak, és a szolgáltatás funkcionalitását a legszéleskörűbben a HTTP megfelelő funkcióin keresztül teszik elérhetővé.
16

Én is pont ezek miatt nem

Hidvégi Gábor · 2013. Aug. 14. (Sze), 17.40
Én is pont ezek miatt nem értem inf3rnot és a kérdéseit.
17

:)

MadBence · 2013. Aug. 14. (Sze), 19.21
REST az, amit annak hívnak :)
18

Kérdés, ha különböző emberek

Joó Ádám · 2013. Aug. 14. (Sze), 19.32
Kérdés, ha különböző emberek különböző dolgokat hívnak REST-nek, akkor mi REST :)
19

rest fn USA: re'st UK: rest:

inf3rno · 2013. Aug. 14. (Sze), 21.14
rest fn USA: re'st UK: rest: pihenés, nyugvás, alvás, nyugvópont, nyugalmi helyzet, zene, pauza, megállás, pihenőhely, pihenőszoba, támasztó, támaszték, állvány, pillér, támoszlop
20

Azt írják a sütire, hogy

inf3rno · 2013. Aug. 14. (Sze), 21.17
Azt írják a sütire, hogy azért nem jó, mert minden kérésnek tartalmaznia kell minden adatot, ami a kiszolgálásához szükséges (mondjuk a cookie-t szintén header-ben küldik ugyanúgy, mint a basic auth-nál a felh nevet és jelszót, úgyhogy én sem teljesen értem, hogy miért nem jó). Én amúgy is küldenék csrf miatt header-ben vagy qs-ben tokent, szóval nekem lényegtelen, hogy használok e cookie-t vagy sem. SSL-nél cookie-val is ugyanúgy biztonságos lenne, de majd később mérlegelem, hogy szükségem van e arra.
22

A session süti nem tartalmaz

tgr · 2013. Aug. 15. (Cs), 18.40
A session süti nem tartalmaz minden adatot, csak egy azonosítót, a tényleges adatokat a szerver a session fájlban tárolja. Hacsak nem tárolod magát a jelszót sütiben, ami általában nem jó ötlet.
23

Kik írják, hogy nem jó? A

Joó Ádám · 2013. Aug. 15. (Cs), 19.14
Kik írják, hogy nem jó? A munkamenet-azonosító pont ugyanaz, mint egy felhasználónév-jelszó pár, csak nem felhasználóbarát, és korlátozott a szavatossága. Nyugodtan használj sütit.
25

Amíg nincs ssl, addig jobb a

inf3rno · 2013. Aug. 15. (Cs), 21.46
Amíg nincs ssl, addig jobb a sütinél, ha minden kéréssel küldök token-t, az nem támadható csrf-re.
27

A CSRF csak adatbázist

Joó Ádám · 2013. Aug. 15. (Cs), 23.13
A CSRF csak adatbázist módosító műveletek esetén releváns, azt meg amúgyis csak POST-ban küldesz, és mehet vele a token. De nem teljesen értelek.
28

Meg put, patch, delete esetén

inf3rno · 2013. Aug. 15. (Cs), 23.51
Meg put, patch, delete esetén is... Akkor meg már egyszerűbb így automatikusan mindig kiküldeni.
24

Az OAuth (2) autorizációs és

tgr · 2013. Aug. 15. (Cs), 19.25
Az OAuth (2) autorizációs és nem autentikációs protokoll(család). Ha autentikációra próbálod használni, rossz dolgok történnek.
26

Ja, közben jobban

inf3rno · 2013. Aug. 15. (Cs), 21.47
Ja, közben jobban utánanéztem, és leesett...