Úvod
ověřování založené na tokenu je dnes na webu prominentní všude. Většina webových společností používá API, tokeny jsou nejlepší způsob, jak zvládnout ověřování pro více uživatelů.
při výběru autentizace založené na tokenu pro vaši aplikaci existují některé velmi důležité faktory. Hlavní důvody pro žetony jsou:
- bez státní příslušnosti a škálovatelné servery
- mobile application ready
- předejte ověření jiným aplikacím
- Extra security
kdo používá ověřování založené na tokenu?
jakékoli hlavní API nebo webové aplikace, na které jste narazili, s největší pravděpodobností použily tokeny. Aplikace jako Facebook, Twitter, Google+, GitHub a mnoho dalších používají tokeny.
pojďme se podívat na to, jak přesně to funguje.
proč tokeny obešly
než uvidíme, jak funguje ověřování založené na tokenu a jeho výhody, musíme se podívat na způsob, jakým byla autentizace provedena v minulosti.
autentizace založená na serveru (tradiční Metoda)
vzhledem k tomu, že protokol HTTP je bez státní příslušnosti, znamená to, že pokud ověříme uživatele pomocí uživatelského jména a hesla, pak na další žádost naše aplikace nebude vědět, kdo jsme. Museli bychom se znovu ověřit.
tradičním způsobem, jak si naše aplikace pamatovat, kdo jsme, je ukládat přihlašovací údaje Uživatele na server. To lze provést několika různými způsoby v relaci, obvykle v paměti nebo uložené na disku.
vzhledem k tomu, že web, aplikace a vzestup mobilní aplikace nastaly, tato metoda ověřování ukázala problémy, zejména v škálovatelnosti.
problémy se serverovou autentizací
s touto metodou autentizace vzniklo několik zásadních problémů.
- Sessions: Pokaždé, když je uživatel ověřen, server bude muset vytvořit záznam někde na našem serveru. To se obvykle provádí v paměti a když je mnoho uživatelů ověřujících, zvyšuje se režie na vašem serveru.
- škálovatelnost: protože relace jsou uloženy v paměti, způsobuje to problémy se škálovatelností. Jakmile naši poskytovatelé cloudu začnou replikovat servery, aby zvládli zatížení aplikací, mít důležité informace v paměti relací omezí naši schopnost škálovat.
- CORS: Protože chceme rozšířit naši aplikaci tak, aby byla naše data používána na více mobilních zařízeních, musíme se starat o sdílení zdrojů cross-origin (CORS). Při použití volání AJAX k získání zdrojů z jiné domény (mobilní na náš API server) bychom mohli narazit na problémy se zakázanými požadavky.
- CSRF: budeme mít také ochranu proti padělání žádostí o cross-site (CSRF). Uživatelé jsou náchylní k útokům CSRF, protože již mohou být ověřeni pomocí bankovního webu, což by mohlo být využito při návštěvě jiných webů.
s těmito problémy, škálovatelnost je hlavní, to dávalo smysl vyzkoušet jiný přístup.
jak Token-Based funguje
Token-based authentication je bez státní příslušnosti. Na Serveru ani v relaci neukládáme žádné informace o našem uživateli.
tento koncept se sám stará o mnoho problémů s ukládáním informací na server.
žádné informace o relaci znamená, že vaše aplikace může škálovat a přidat další stroje podle potřeby bez obav o tom, kde je uživatel přihlášen.
ačkoli se tato implementace může lišit, její podstata je následující:
- uživatel požaduje přístup s uživatelským jménem / heslem
- aplikace ověřuje pověření
- aplikace poskytuje podepsaný token klientovi
- klient ukládá tento token a odešle jej spolu s každým požadavkem
- Server ověřuje token a odpovídá daty
každý jednotlivý požadavek bude vyžadovat token. Tento token by měl být odeslán v hlavičce HTTP, abychom se drželi myšlenky požadavků HTTP bez státní příslušnosti. Budeme také muset nastavit náš server tak, aby přijímal požadavky ze všech domén pomocí Access-Control-Allow-Origin: *. Co je zajímavé o označení * v záhlaví ACAO je to, že neumožňuje žádosti o zadání pověření, jako je ověřování HTTP, SSL certifikáty na straně klienta nebo soubory cookie.
jakmile jsme ověřili naše informace a máme náš token, jsme schopni s tímto tokenem dělat mnoho věcí.
mohli bychom dokonce vytvořit Token založený na oprávnění a předat jej aplikaci třetí strany (řekněme novou mobilní aplikaci, kterou chceme použít) a budou mít přístup k našim datům – ale pouze k informacím, které jsme povolili s tímto konkrétním tokenem.
výhody tokenů
bez státní příslušnosti a škálovatelné
tokeny jsou uloženy na straně klienta. Zcela bez státní příslušnosti a připraven být zmenšen. Naše vyvažovače zatížení jsou schopny předat uživatele na některý z našich serverů, protože nikde nejsou žádné informace o stavu ani relaci.
pokud bychom měli uchovávat informace o relaci o uživateli, který byl přihlášen, vyžadovalo by to, abychom jej posílali na stejný server, na kterém se přihlásili (tzv. session affinity).
to přináší problémy, protože někteří uživatelé by byli nuceni ke stejnému serveru a to by mohlo přinést místo silného provozu.
nebojte se! Tyto problémy jsou pryč s tokeny, protože token sám drží data pro tohoto uživatele.
zabezpečení
token, nikoli soubor cookie, je odeslán na každou žádost a protože není odeslán žádný soubor cookie, pomáhá to zabránit útokům CSRF. I když vaše konkrétní implementace ukládá token do souboru cookie na straně klienta, soubor cookie je pouze mechanismem ukládání namísto autentizačního. Neexistují žádné informace založené na relacích, které by bylo možné manipulovat, protože nemáme relaci!
token také vyprší po nastaveném čase, takže se uživatel bude muset znovu přihlásit. To nám pomáhá zůstat v bezpečí. Existuje také koncept zrušení tokenu, který nám umožňuje zneplatnit konkrétní token a dokonce i skupinu tokenů na základě stejného udělení oprávnění.
rozšiřitelnost(přítel přítele a oprávnění)
tokeny nám umožní vytvářet aplikace, které sdílejí oprávnění s jiným. Například jsme propojili náhodné sociální účty s našimi hlavními, jako je Facebook nebo Twitter.
když se přihlásíme na Twitter prostřednictvím služby (řekněme Buffer), umožňujeme bufferu zveřejňovat příspěvky do našeho Twitter streamu.
pomocí tokenů poskytujeme selektivní oprávnění aplikacím třetích stran. Mohli bychom dokonce vytvořit vlastní API a rozdávat speciální tokeny oprávnění, pokud naši uživatelé chtěli dát přístup ke svým datům jiné aplikaci.
více platforem a domén
mluvili jsme o CORS dříve. Když se naše aplikace a služby rozšíří, budeme muset poskytovat přístup ke všem druhům zařízení a aplikací (protože naše aplikace se určitě stane populární!).
díky tomu, že naše API slouží pouze datům, můžeme také zvolit návrh, který bude sloužit aktivům z CDN. To eliminuje problémy, které CORS vyvolá poté, co jsme nastavili rychlou konfiguraci záhlaví pro naši aplikaci.
Access-Control-Allow-Origin: *naše data a zdroje jsou nyní k dispozici požadavkům z jakékoli domény, pokud má uživatel platný token.
standardy založené
při vytváření tokenu máte několik možností. Budeme se více ponořit do tohoto tématu, když zabezpečíme API v následném článku, ale standardem pro použití by byly webové tokeny JSON.
tento šikovný debugger a knihovna graf ukazuje podporu pro JSON webové tokeny. Můžete vidět, že má velkou podporu v různých jazycích. To znamená, že byste mohli skutečně vypnout svůj ověřovací mechanismus, pokud se tak rozhodnete v budoucnu!
závěr
byl to jen pohled na to, jak a proč ověřování založené na tokenu. Jak je tomu vždy ve světě bezpečnosti, ke každému tématu je mnohem více a liší se podle případu použití. Dokonce jsme se ponořili do některých témat škálovatelnosti, která si zaslouží i vlastní konverzaci.
jednalo se o rychlý přehled na vysoké úrovni, takže neváhejte poukázat na vše, co bylo zmeškáno, nebo na jakékoli dotazy, které máte k této záležitosti.
v našem dalším článku se podíváme na anatomii webových tokenů JSON.
Poznámka: přidání informací o hlavičce ACAO a CSRF objasnění (díky Emily Starkové za informace o článku)