Homepage » Internet » Mi az OAuth Connect és hogyan kell használni

    Mi az OAuth Connect és hogyan kell használni

    Sokan kapcsolatba lépnek az OAuth-szal, amikor böngészünk az interneten, és a legtöbbünk nem is tudja, hogy létezik. Az OAuth (Open Authentication) egy olyan rendszer, amely harmadik fél weboldalainak korlátozott hozzáférést biztosít a felhasználói fiókokhoz, például a Twitter vagy a Facebook fiókjaihoz. Lehetővé teszi a látogatók közötti interakciót a webhelyen anélkül, hogy új fiókregisztrációra lenne szükség, vagy a felhasználónevét és jelszavát harmadik felek számára.

    Ebben az útmutatóban szeretném bemutatni az OAuth koncepcióját és azt, hogy hogyan alkalmazható a fejlesztők. Számos technikai részlet van a saját OAuth alkalmazásának megvalósításában. A példámat PHP-ben írom egy Twitter könyvtárcsomagolással, de szinte bármilyen népszerű programozási API-t használhat a Python-tól Ruby vagy Objective-C-hez..

    Még akkor is, ha a koncepció rejtélyesnek tűnik, próbáljon megemészteni, amennyit csak tudsz. Még mindig egy nagyon titokzatos technológia, melyet éppen 2007-ben készítettek el. Biztosan nem értettem, hogyan fejleszthetem teljes OAuth kapcsolatokat az első néhány oktatóanyagom után, de ha ragaszkodsz hozzá, akkor gyorsan fogsz fogni. Most először rúgd ki a dolgokat, egy kis bevezetést!

    Milyen problémákat oldhatunk meg?

    Ha figyelembe vesszük, hogy mennyi összekapcsolták az internetet, akkor csak akkor van értelme, ha a felhasználók meg akarják osztani az információkat több fiók között a Facebookról a Twitterre, a Tumblrra, a Foursquare-ra és most még a mobilalkalmazásokra, például a Path vagy Instagram-re. Az a probléma, amellyel most szembesülünk, az, hogy ezt a lehető legbiztonságosabb és legegyszerűbb módon lehessen megvalósítani. Az OAuth 1.0 egy kísérlet arra, hogy megoldja ezt és számos más problémát a korábbi OpenID szabványokhoz képest. A felhasználók még mindig megadják a felhasználónevüket / jelszavukat a harmadik fél weboldalain, csak azért, hogy csatlakozzanak az OpenID-hez. Ez nem teszi biztonságosabbnak a felhasználó számára. Az OAuth specifikációk alapján a felhasználónak nem kell személyes fiókadatokat tárolni harmadik fél adatbázisába.

    (Képforrás: Martin Hassman)

    Az OAuth segítségével a fő fiókszolgáltató (például Twitter, Facebook) először átirányítja Önt (a felhasználót) egy engedélyezési oldalra. A felhasználó ezután bejelentkezik a fő hálózatba, majd elfogadja vagy tagadja az új kapcsolatot a harmadik fél weboldalán. A technológia fájdalommentes, és bármikor engedélyezheti a kapcsolatokat a fiókbeállításaitól. Figyelje meg, hogy a jelszavát soha nem adja meg a harmadik félnek, amely ezt a protokollt sokkal biztonságosabbá teszi, mint a partner.

    Hogyan működik a folyamat?

    A szabványos OAuth-hívásban 3 fél veszi figyelembe:

    • Szolgáltató - A fő hálózat, amelyről adatokat szeretne húzni. Ezek az API-válaszokat, például a felhasználónevet, a profilképet, a webhely URL-jét és az egyéb dolgokat biztosítják.
    • Fogyasztó - A harmadik féltől származó alkalmazás, amely adatokat szeretne fogadni. Ez lenne az a webhely vagy mobilalkalmazás, amely az első csatlakozási kérelmet teszi, majd az engedélyezés után kezeli a visszatérési adatokat.
    • használó - Az a személy, aki a számítógép mögött ül, és az Ön webhelyeivel kommunikál!

    Az OAuth célja nem egy adott könyvtár használata a webhelyek számára. Valójában az “szabályok” nyílt protokoll API létrehozásához. Tehát bár mindannyian hasznot húzhatunk a technológiából, valójában a fejlesztők, akik valóban érdeklődni fognak ezen a területen. Ha további információra van szüksége, nézze meg a 2010 áprilisában kiadott felülvizsgált verziót.

    Szemvédelem

    A teljes folyamat végül 2 különböző kulcsot igényel egy hozzáférési token mellett. A kulcsokat a gyökérszolgáltatás biztosítja, miután regisztrálta az alkalmazást ügyfél és titkos azonosító. Az ügyfélazonosító általában átkerül a hitelesítési URL-címbe, így a kiszolgáló felismeri az alkalmazást.

    A titkos azonosító a kódban van, így a kiszolgáló ellenőrizheti az alkalmazás azonosságát. Hasonlóképpen a távoli kiszolgáló a saját titkos azonosítójával is megegyezik, így nem hibásan küld egy Twitter-kérést a Facebook API-jára, vagy fordítva. Ha a felhasználó engedélyezi a kapcsolatot és az összes kulcs megegyezik, akkor a kódot véletlenszerű számok és betűk hosszú kódjával visszaküldi a webhelyére.

    Ezt a kódot használják egy új létrehozására hozzáférési token. Ezek hasonlóak a munkamenetváltozókhoz, amelyeket a cookie-kban tárolhat, hogy a felhasználó bejelentkezzen a webhelyére. Az egyetlen különbség az, hogy sok szolgáltatás hozzáférési token és titkos hozzáférési token küld vissza. Valószínűleg mindkettőre szüksége lesz, ha bármilyen adatot húz a szerverről. Példa lehet arra, hogy a felhasználó profilfotójával másolatot menthet a saját webhelyére.

    Példa könyvtár a Twitter OAuth számára

    A fejlesztők gyakran nem indulnak semmiből, akkor miért ne nézzünk meg egy korábban épített könyvtárat? Ez megment minket az időnk és a fejfájás miatt, amikor a PHP-vel dolgozunk. Nézzük meg, hogyan építsünk egy igazán egyszerű példát a Twitter API tetején.

    Nagyon ajánlom Jinus Mathai Twitter Async-et a GitHubon. Tökéletesen működik, és még néhány nagyon egyszerű példakódot is biztosít, amit megnézhetünk. Most letöltheti a .zip-et, de mielőtt megnéznénk a kódot, regisztrálnunk kell és be kell szereznünk az alkalmazás azonosítóit a Twitter-ből.

    Új alkalmazás regisztrálása

    A Twitter Dev Center egy nagyszerű erőforrás azok számára, akik most kezdték meg az API-t. Néhány év alatt sokszor írták és írták át. A kívánt oldal https://dev.twitter.com/apps/new. Megkéri, hogy jelentkezzen be először, majd meg kell adnia néhány hitelesítő adatot egy új alkalmazáshoz.

    Az alkalmazás neve és leírása akkor jelenik meg, ha a felhasználó a Twitteren engedélyezi. A webhely URL-je szintén fontos a harmadik fél címének megkülönböztetéséhez. Könnyebb lenne egy élő domainrel dolgozni, bár a localhost-ot tesztelésre használhatja, de nem támogatom ezt a módszert. Ugyanolyan egyszerű bejelentkezni egy ingyenes internetes fogadóra, és onnan futtatni a szkriptet.

    A visszahívási URL a végső rendeltetési helyként szerepel, miután a látogatók elfogadják vagy tagadják az engedélyt. A programozó feladata, hogy olvassa el a Twitter válaszát, és ennek megfelelően küldjön üzenetet. Az Async könyvtárban már rendelkezünk néhány hitelesítő adattal, de nem fognak működni, mivel a visszahívási URL egy külső bloghoz van megadva. Ha egy teljesen csatlakoztatott OAuth webalkalmazást szeretne felépíteni, az alábbiakban néhány részletes bemutatót vettem fel.

    Nézze meg a kódot

    Ha távoli internetes gazdagépet használ, érdemes lehet az Async-könyvtárakat kicsomagolni és új könyvtárba feltölteni. Ellenkező esetben csak megnézheti a forráskódot. Valószínűleg nem tudunk új kapcsolatot húzni. A forráskód feltöltésével és szerkesztésével kapcsolatos gyakorlati tapasztalat azonban mindig tanulási folyamat.

    A gyökérkönyvtárban egy megnevezett script található simpleTest.php. A belső rész egy csomó PHP kódot tartalmaz, amelyek az OAuth könyvtárakhoz kapcsolódnak. Nem tudom megtenni mindent együtt, de meg kell vizsgálnunk egy fontos kódblokkot, hogy megállapítsuk a figyelemre méltó részleteket.

     

    Négy nagyon fontos változó van a fogyasztói kulcs és a titkos azonosító számára, valamint a token és titkos token azonosító. Nem minden API szolgáltatás igényli ezt a 4-es készletet, de ez a megfelelő OAuth protokoll. Az EpiTwitter osztály mind a 4 értéket paraméterként adja meg, és létrehozza a kapcsolat URL-jét a Twitter-be.

    https://api.twitter.com/oauth/authorize?oauth_token=TOKEN_ID_HERE

    Ezzel az új dinamikus URL-címmel bejelentkezési gombot hozhat létre a felhasználók számára. Ez először egy biztonságos Twitter API oldalra irányítja őket, ahol a felhasználó elfogadja vagy tagadja a kapcsolatot. Függetlenül attól, hogy választott-e, a felhasználó átirányítja az alkalmazás visszahívási URL-jét. A teljes nyílt protokoll nagyon tiszta perspektívával rendelkezik, amely lehetővé teszi a gyors fejlődést, különösen a gyakorlatilag minden nyelven elérhető könyvtárak esetében.

    kapcsolódó linkek

    • hueniverse oauth 1.0 útmutató
    • Gyengéd Bevezetés az OAuth-ba
    • OAuth GYIK
    • Facebook hitelesítési eszköz útmutató
    • Egyszerű Twitter OAuth Signin
    • Az OAuth használata Twitteren a Kakaó Célkitűzésben
    • OAuth intelligens fogyasztása Rails-ben

    Következtetés

    Remélhetőleg ez a bevezetés az OAuth-ba érdekelte az alkalmazások felépítését a protokollon keresztül. Sok fejlesztő igyekezett ilyen megoldást keresni, és az OAuth 2.0 lehet az összekapcsolt szociális hálózatok jövője. Már több mint két tucat kapcsolatot használok a Twitter fiókomban, és tényleg lenyűgözött a fejlesztői dokumentáció!

    Nyilvánvaló, hogy ebben a témában sokat mondhatunk. Ez nem olyan dolog, amit teljes egészében egy ülésen dolgozhat fel. Böngésszen a neten, hogy több OAuth megoldást találjon, és tudassa velünk a gondolatait az alábbiakban bemutatott vita területen.