Bevezetés
a Token alapú hitelesítés manapság mindenütt kiemelkedő az interneten. A legtöbb webes vállalat API-t használ, a tokenek a legjobb módja a hitelesítés kezelésének több felhasználó számára.
van néhány nagyon fontos tényező az alkalmazás token alapú hitelesítésének kiválasztásakor. A tokenek fő okai:
- hontalan és skálázható szerverek
- mobil alkalmazás kész
- adja át a hitelesítést más alkalmazásoknak
- Extra biztonság
ki használ Token alapú hitelesítést?
bármely nagyobb API vagy webes alkalmazás, amellyel találkozott, valószínűleg tokeneket használt. Az olyan alkalmazások, mint a Facebook, a Twitter, a Google+, a GitHub és még sok más, tokeneket használnak.
vessünk egy pillantást pontosan hogyan működik.
miért jöttek létre a tokenek
mielőtt látnánk, hogyan működik a token alapú hitelesítés és annak előnyei, meg kell vizsgálnunk, hogyan történt a hitelesítés a múltban.
szerver alapú hitelesítés (a hagyományos módszer)
mivel a HTTP protokoll hontalan, ez azt jelenti, hogy ha felhasználónévvel és jelszóval hitelesítünk egy felhasználót, akkor a következő kérésre alkalmazásunk nem fogja tudni, kik vagyunk. Újra hitelesítenünk kellene.
a hagyományos módja annak, hogy alkalmazásaink emlékezzenek arra, hogy kik vagyunk, a felhasználó bejelentkezett információinak tárolása a szerveren. Ezt meg lehet tenni néhány különböző módon a munkamenet, általában a memóriában vagy a lemezen tárolt.
mivel a web, az alkalmazások és a mobil alkalmazás felemelkedése megtörtént, ez a hitelesítési módszer problémákat mutatott, különösen a skálázhatóság terén.
a szerver alapú hitelesítéssel kapcsolatos problémák
néhány nagyobb probléma merült fel ezzel a hitelesítési módszerrel.
- ülések: Minden alkalommal, amikor egy felhasználó hitelesítésre kerül, a szervernek létre kell hoznia egy rekordot valahol a szerverünkön. Ez általában a memóriában történik, és amikor sok felhasználó hitelesíti, a szerveren a rezsi növekszik.
- skálázhatóság: mivel a munkamenetek a memóriában vannak tárolva, ez problémákat okoz a skálázhatósággal kapcsolatban. Amint a felhőszolgáltatóink elkezdenek replikálni a szervereket az alkalmazásterhelés kezelésére, a létfontosságú információk jelenléte a munkamenet memóriájában korlátozza a méretezési képességünket.
- CORS: Mivel bővíteni szeretnénk alkalmazásunkat, hogy adatainkat több mobil eszközön is felhasználhassuk, aggódnunk kell a cross-origin resource sharing (CORS) miatt. Ha AJAX hívásokat használ egy másik tartomány erőforrásainak megragadására (mobil az API szerverünkre), problémákba ütközhetünk a tiltott kérésekkel.
- CSRF: védelmet nyújtunk a webhelyek közötti kérelemhamisítás (CSRF) ellen is. A felhasználók hajlamosak a CSRF támadásokra, mivel már hitelesíthetők mondjuk egy banki webhelyen, és ezt ki lehet használni más webhelyek látogatásakor.
ezekkel a problémákkal, mivel a skálázhatóság volt a fő, érdemes más megközelítést kipróbálni.
hogyan működik a Token alapú
a Token alapú hitelesítés hontalan. Nem tárolunk semmilyen információt a felhasználónkról a szerveren vagy egy munkamenetben.
ez a koncepció önmagában gondoskodik a szerveren tárolt információk sok problémájáról.
nincs munkamenetinformáció azt jelenti, hogy az alkalmazás szükség szerint méretezhet és hozzáadhat további gépeket anélkül, hogy aggódna a felhasználó bejelentkezésének helye miatt.
bár ez a megvalósítás változhat, lényege a következő:
- User Requests Access with Username / Password
- Application validates credentials
- az alkalmazás aláírt tokent biztosít az ügyfélnek
- Client tárolja ezt a Tokent, és elküldi azt minden kéréssel együtt
- A Server ellenőrzi a Tokent, és az adatokkal válaszol
minden egyes kéréshez szükség lesz a Tokenre. Ezt a tokent a HTTP fejlécben kell elküldeni, hogy megtartsuk a hontalan HTTP kérések gondolatát. Azt is be kell állítanunk a szerverünket, hogy fogadja az összes domain kérését a Access-Control-Allow-Origin: *használatával. Az acao fejlécében a * megjelölés érdekessége, hogy nem engedélyezi a hitelesítő adatok, például a HTTP-hitelesítés, az ügyféloldali SSL-tanúsítványok vagy a cookie-k megadását.
miután hitelesítettük az adatainkat, és megvan a tokenünk, sok mindent meg tudunk csinálni ezzel a tokennel.
akár engedélyalapú tokent is létrehozhatunk, és ezt továbbadhatjuk egy harmadik féltől származó alkalmazásnak (mondjuk egy új mobilalkalmazásnak, amelyet használni akarunk), és hozzáférhetnek az adatainkhoz-de csak azokhoz az információkhoz, amelyeket az adott tokennel engedélyeztünk.
a tokenek előnyei
hontalan és skálázható
tokenek a kliens oldalon vannak tárolva. Teljesen hontalan és készen áll a méretezésre. Terheléselosztóink képesek átadni a felhasználót bármelyik szerverünknek, mivel sehol nincs állapot-vagy munkamenet-információ.
ha egy bejelentkezett felhasználó munkamenetinformációit szeretnénk megőrizni, akkor ehhez arra lenne szükség, hogy a felhasználót továbbra is ugyanarra a kiszolgálóra küldjük, amelyen bejelentkezett (úgynevezett munkamenet-affinitás).
ez problémákat okoz, mivel egyes felhasználók ugyanarra a szerverre kényszerülnek, és ez nagy forgalmat eredményezhet.
ne aggódj! Ezek a problémák eltűntek a tokenekkel, mivel maga a token tárolja az adott felhasználó adatait.
biztonság
a token, nem egy süti, minden kérésre elküldésre kerül, és mivel nem küld cookie-t, ez segít megelőzni a CSRF támadásokat. Még akkor is, ha az adott megvalósítás a tokent egy cookie-ban tárolja az ügyféloldalon, a cookie csupán tárolási mechanizmus, nem pedig hitelesítési mechanizmus. Nincs manipulálható munkamenet-alapú információ, mivel nincs munkamenetünk!
a token egy meghatározott idő elteltével is lejár, így a felhasználónak újra be kell jelentkeznie. Ez segít biztonságban maradni. Létezik a token visszavonásának fogalma is, amely lehetővé teszi számunkra, hogy érvénytelenítsünk egy adott tokent, sőt egy tokencsoportot ugyanazon engedélyezési támogatás alapján.
bővíthetőség (egy barát barátja és engedélyek)
a tokenek lehetővé teszik számunkra, hogy olyan alkalmazásokat építsünk, amelyek megosztják az engedélyeket egy másikkal. Például véletlenszerű közösségi fiókokat kapcsoltunk össze a főbb fiókjainkkal, például a Facebook vagy a Twitter.
amikor egy szolgáltatáson keresztül jelentkezünk be a Twitterbe (mondjuk puffer), megengedjük, hogy Buffer posztoljon a Twitter-adatfolyamunkba.
tokenek használatával így biztosítjuk a szelektív engedélyeket harmadik féltől származó alkalmazásokhoz. Akár saját API-t is készíthetünk, és külön engedély tokeneket oszthatunk ki, ha a felhasználók hozzáférést akarnak adni az adataikhoz egy másik alkalmazáshoz.
több platform és domain
korábban beszéltünk egy kicsit a CORS-ról. Amikor alkalmazásunk és szolgáltatásunk kibővül, hozzáférést kell biztosítanunk mindenféle eszközhöz és alkalmazáshoz (mivel alkalmazásunk minden bizonnyal népszerűvé válik!).
miután API-Junk csak adatokat szolgáltat, a tervezési választást is MEGHOZHATJUK, hogy az eszközöket CDN-ből szolgáljuk ki. Ez kiküszöböli a CORS által felvetett problémákat, miután beállítottuk az alkalmazás gyors fejléc-konfigurációját.
Access-Control-Allow-Origin: *adataink és erőforrásaink mostantól bármely tartományból kérhetők, amennyiben a felhasználó rendelkezik érvényes tokennel.
szabványalapú
a token létrehozásakor van néhány lehetőség. Jobban belemerülünk ebbe a témába, amikor egy API-t egy nyomon követési cikkben rögzítünk, de a használandó szabvány a JSON Web Token lenne.
ez a praktikus hibakereső és könyvtárdiagram a JSON webes tokenek támogatását mutatja. Láthatjuk, hogy van egy nagy mennyiségű támogatást szerte a különböző nyelveken. Ez azt jelenti, hogy valóban kikapcsolhatja a hitelesítési mechanizmust, ha a jövőben ezt választja!
következtetés
ez csak egy pillantás volt a token alapú hitelesítés hogyan és miért. Mint mindig a biztonság világában, az egyes témákban sokkal több van, és felhasználási esetenként változik. Még a skálázhatóság néhány témájába is belemerültünk, amely megérdemli a saját beszélgetését is.
ez egy magas szintű gyors áttekintés volt, ezért kérjük, bátran mutasson bármit, ami hiányzott, vagy bármilyen kérdése van az ügyben.
következő cikkünkben a JSON webes tokenek anatómiáját vizsgáljuk.
Megjegyzés: hozzáadása ACAO fejléc info és CSRF pontosítások (köszönet Emily Stark a cikk info)