Weblabor

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