Fontos tudnivalók az OAuth-ról

Az OAuthról minden fejlesztőnek tudnia kell. Ha önálló alkalmazást vagy harmadik féltől származó alkalmazást készít, amely integrálódik valamilyen más HTTP szolgáltatással, akkor tudnia kell az OAuth működését, hogy a felhasználóinak könnyen használható és jól integrált szolgáltatást nyújtson.

Az elképzelés az, hogy az ügyfélalkalmazásoknak korlátozott hozzáférést biztosítanak a felhasználói információkhoz anélkül, hogy valaha megosztanák a felhasználói adatokat vagy jelszavakat. Az OAuth keretrendszer felelős azokért a cserékért, amelyek szükségesek ahhoz, hogy egy alkalmazás megkapja az Ön adatait.

Tegyük fel, hogy regisztrálni szeretne a Dev-re.(ami remek hely a fejlesztők számára az eszmecserére) lehetővé teszik, hogy regisztráljon a GitHub-fiókjával. Hogyan történik ez? Honnan tudhatnák, hogy Ön a GitHub-fiók tulajdonosa, amelyre regisztrál?

Ennél is fontosabb, hogyan tudja biztosítani, hogy a Dev.nem lépi túl a határait, amikor a GitHub-ban tárolt adatairól van szó?

OAuth résztvevők

Maradunk az Atom szerkesztő GitHub bővítményének példáján, amely lehetővé teszi a fejlesztők számára, hogy közvetlenül az Atom kezelőfelületén tegyenek kódot a GitHub-ba. Ennek oka például az, hogy a GitHub nem rejti el a részleteket a színfalak mögött, és láthatja, mi folyik a motorháztető alatt.

Mielőtt az OAuth működésének apróságaiba kerülnénk. Állítsuk be a színpadot a cserében résztvevők felismerésével:

1. Erőforrás tulajdonosa vagy felhasználó: Ez a felhasználó az, akinek a fiókadataihoz hozzá kell férni (olvasni és / vagy írni) ahhoz, hogy működni tudjon egy alkalmazással.
2. Ügyfél: Ez az az alkalmazás, amely engedélyét kéri az Ön adatainak eléréséhez egy másik szolgáltatásból. Példánkban az Atom szerkesztője az ügyfél.
3. Forrás: Az erőforrás az a tényleges információ, amely valamilyen távoli helyen a szervereken ül. Ez API-n keresztül érhető el, ha az ügyfél megfelelő engedélyeket kap.
4. Authorization Server: API-val is kapcsolódik. Ezt a szervert a szolgáltató tartja fenn (példánkban a GitHub). Az engedélyezési kiszolgálóra és az erőforrás-kiszolgálóra egyaránt API-ként hivatkozunk, mert azokat egy entitás, jelen esetben a GitHub kezeli, és API-ként teszik ki az ügyfél fejlesztőjének.

OAuth regisztráció

A folyamat az ügyfélalkalmazás fejlesztésekor kezdődik. Lépjen az erőforrás-szolgáltatóhoz, és regisztráljon a fejlesztői portálon vagy a webhely API-szakaszán. Meg kell adnia egy visszahívási URL-t is, ahova a felhasználót elfogadása vagy elutasítása után átirányítják, hogy megadja az alkalmazás számára a szükséges engedélyeket.

Például, ha a GitHub → Beállítások → Fejlesztői beállítások menüpontra lép, és a gombra kattint „Új alkalmazás regisztrálása”. Ez biztosítaná a Ügyfélazonosító amely nyilvánosságra hozható és a Ügyféltitok amelyet a fejlesztő szervezetnek titokban kell tartania.

Miután az ügyfél-azonosítót és a titkot megadta Önnek, a fejlesztőnek, Önnek kell tartsa biztonságban őket, mivel az Engedélyező kiszolgáló nem fogja újra megmutatni. Ugyanez vonatkozik minden más zsetonra, amelyet fel lehet dobni (További információ a tokenekről később).

OAuth 2 munkafolyamat

Regisztrálta jelentkezését. Fejlesztették és tesztelték, és most a felhasználók készek használni. Ha új felhasználó regisztrál a szolgáltatásához, megjelenik a „Bejelentkezés a GitHub szolgáltatással” lehetőség. Ez az első lépés.

1. lépés: Engedélyezési kérelem

Az engedélyezési kérelem az a rész, ahol egy új ablak (vagy hasonló prompt) nyílik meg az erőforrás weboldalával, és arra kéri a felhasználókat, hogy jelentkezzenek be. Ha már be van jelentkezve, azon az eszközön, akkor ezt a lépést kihagyja, és a GitHub egyszerűen megkérdezi, hogy hozzáférést kíván-e adni az Atom kliens alkalmazáshoz. Ez sokkal átláthatóbb az Atom esetében, mert arra kérik, hogy manuálisan keresse fel a GitHub webhelyét, és adja meg nekik az engedélyt.

Az URL meglátogatásakor engedélyt kér.

Figyelje meg az URL-t, amely megmutatja, hogy ez egy biztonságos (HTTPS) weboldal a GitHub részéről.Inc. Most te, a felhasználó, biztos lehetsz benne, hogy közvetlenül lépsz kapcsolatba a GitHub-szal. Az Atom egyszerűen vár, meglehetősen útközben.

Az Atomtól eltérően a legtöbb ügyfélalkalmazás automatikusan feltölti a bejelentkezési vagy engedélyezési oldalt. Bár ez nagyon kényelmes, visszaélni is lehet vele, ha az ügyfélalkalmazás úgy dönt, hogy megnyit egy adathalász linket. Ennek elkerülése érdekében mindig ellenőriznie kell azt az URL-t, amelyre átirányítják, és meg kell győződnie arról, hogy az helyes URL-e és a HTTPS protokollt használja.

2. lépés: Az engedélyezési támogatás megszerzése

Az Atom kliens értesítéséhez kapsz egy tokent (engedélyezési engedélyt), amelyet ezután elküld az Atom kliensnek.

Miután a felhasználó ezt megtette, a felhasználó feladata elkészült. (Valójában egy tipikus felhasználó nincs is tisztában az engedély megadásával. A GitHub példáját választották annak bemutatására, hogy ez történik.

3. lépés: A hozzáférési token megszerzése

A jogosultsági engedély továbbra sem az az entitás, amely hozzáférést biztosít az ügyfélnek a felhasználói információkhoz. Ez úgy érhető el, hogy úgynevezett hozzáférési tokent használunk. Amit az ügyfélalkalmazás megpróbál elérni ebben a lépésben.

Ehhez az ügyfélnek most meg kell adnia az engedélyezési engedélyt az engedélyezési szervernek saját személyazonosságának igazolásával együtt. A személyazonosság ellenőrzése az ügyfélalkalmazáshoz korábban megadott ügyfél-azonosítóval és ügyfél-titokkal történik.

A személyazonosság-ellenőrzés annak biztosítása érdekében történik, hogy a felhasználót ne csalják be egy aljas alkalmazásba, amely úgy tesz, mintha legális alkalmazás lenne. Például, ha valaki úgy dönt, hogy a futtatható fájlt Atomnak nevezi ugyanazzal a névvel, logóval és funkcionalitással, a felhasználó átverheti, hogy hozzáférést ad egy kliensnek, ami visszaélhet az adataival. Az Ön beleegyezése nélkül szimatolhatnak vagy akár cselekedhetnek is. A hitelesítési szerver biztosítja, hogy az ügyfél valóban olyan legyen, mint amilyennek a felhasználók számára látszik.

Miután ellenőrizte a személyazonosságot és elfogadta az engedélyezési engedélyt, az engedélyezési kiszolgáló tokent dob ​​az ügyfélalkalmazásnak. Gondoljon arra, hogy a token mind a felhasználónév, mind a jelszó kombinációja, amely megadható az erőforrás-kiszolgálónak egy adott védett erőforrás eléréséhez, amelyhez az erőforrás-tulajdonos engedélyezte.

Végül a token használatával az alkalmazás hozzáférhet az erőforrás-kiszolgálótól a szükséges felhasználói információkhoz és egyéb erőforrásokhoz.

Figyelje meg, hogyan lehet ebben a teljes cserében a tényleges felhasználónév és jelszó, ahol soha nem osztották meg az ügyféllel? Ez az OAuth szépsége. Ahelyett, hogy felhasználónéveket és jelszavakat adna meg, amelyek az alkalmazás számára hozzáférést biztosítanának az erőforráshoz, helyette tokent használ. És egy token csak korlátozott hozzáférést nyerhet az erőforráshoz.

Engedélyek visszavonása

Tegyük fel, hogy elveszíti hozzáférését eszközéhez, amelyben az engedélyezett ügyfélalkalmazás volt. Jelentkezzen be a GitHub szolgáltatásba, és lépjen a Beállítások → Alkalmazások → Engedélyezett OAuth alkalmazások lehetőségre az engedélyezési engedély és a hozzáférési token visszavonásához. Ugyanezt fogom tenni, mivel a fenti képernyőképeken az Engedélyezési támogatás nyilvánosan megjelent.

Most, hogy madártávlatból megismerheti az OAuth 2 működését.Az engedélyezési engedélyekről és a protokoll egyéb finomabb részleteiről, valamint az API-hívások végrehajtásáról itt olvashat bővebben.