introduktion
tokenbaseret godkendelse er fremtrædende overalt på nettet i dag. Med de fleste internetfirmaer, der bruger en API, er tokens den bedste måde at håndtere godkendelse på for flere brugere.
der er nogle meget vigtige faktorer, når du vælger token-baseret godkendelse til din ansøgning. Hovedårsagerne til tokens er:
- statsløse og skalerbare servere
- mobil applikation klar
- Pass godkendelse til andre applikationer
- ekstra sikkerhed
Hvem bruger tokenbaseret godkendelse?
enhver større API eller internetapplikation, som du er stødt på, har sandsynligvis brugt tokens. Applikationer som Facebook, Kvidre, Google+, GitHub, og så mange flere bruger tokens.
lad os se på præcis, hvordan det virker.
hvorfor Tokens Kom rundt
før vi kan se, hvordan tokenbaseret godkendelse fungerer og dens fordele, er vi nødt til at se på, hvordan godkendelse er blevet gjort i fortiden.
serverbaseret godkendelse (den traditionelle metode)
da HTTP-protokollen er statsløs, betyder det, at hvis vi godkender en bruger med et brugernavn og en adgangskode, så ved den næste anmodning, ved vores applikation ikke, hvem vi er. Vi bliver nødt til at godkende igen.
den traditionelle måde at få vores applikationer til at huske, hvem vi er, er at gemme brugerindloggede oplysninger på serveren. Dette kan gøres på et par forskellige måder på sessionen, normalt i hukommelsen eller gemt på disken.
da internettet, applikationer og stigningen i mobilapplikationen er sket, har denne godkendelsesmetode vist problemer, især i skalerbarhed.
problemerne med serverbaseret godkendelse
der opstod et par store problemer med denne godkendelsesmetode.
- sessioner: Hver gang en bruger er godkendt, skal serveren oprette en post et eller andet sted på vores server. Dette gøres normalt i hukommelsen, og når der er mange brugere, der godkender, øges overhead på din server.
- skalerbarhed: da sessioner er gemt i hukommelsen, giver dette problemer med skalerbarhed. Da vores cloud-udbydere begynder at replikere servere til at håndtere applikationsbelastning, vil det at have vigtige oplysninger i sessionshukommelsen begrænse vores evne til at skalere.
- CORS: Da vi ønsker at udvide vores applikation for at lade vores data bruges på tværs af flere mobile enheder, er vi nødt til at bekymre os om ressourcedeling på tværs af oprindelse (CORS). Når vi bruger opkald til at hente ressourcer fra et andet domæne (mobil til vores API-server), kan vi løbe ind i problemer med forbudte anmodninger.
- CSRF: vi vil også have beskyttelse mod forfalskning på tværs af steder (CSRF). Brugere er modtagelige for CSRF-angreb, da de allerede kan godkendes med f.eks.
med disse problemer, skalerbarhed er den vigtigste, var det fornuftigt at prøve en anden tilgang.
hvordan Token-baserede værker
Token-baseret godkendelse er statsløs. Vi gemmer ikke oplysninger om vores bruger på serveren eller i en session.
dette koncept alene tager sig af mange af problemerne med at skulle gemme information på serveren.
ingen sessionsoplysninger betyder, at din applikation kan skalere og tilføje flere maskiner efter behov uden at bekymre sig om, hvor en bruger er logget ind.
selvom denne implementering kan variere, er kernen i den som følger:
- brugeranmodninger adgang med Brugernavn / Adgangskode
- ansøgning validerer legitimationsoplysninger
- Ansøgning giver et underskrevet token til klienten
- klient gemmer det token og sender det sammen med hver anmodning
- Server verificerer token og reagerer med data
hver enkelt anmodning kræver token. Dette token skal sendes i HTTP-overskriften, så vi holder med ideen om statsløse HTTP-anmodninger. Vi bliver også nødt til at indstille vores server til at acceptere anmodninger fra alle domæner ved hjælp af Access-Control-Allow-Origin: *. Hvad der er interessant ved at udpege * i Acao-overskriften er, at det ikke tillader anmodninger om at levere legitimationsoplysninger som HTTP-godkendelse, SSL-certifikater på klientsiden eller cookies.
når vi har godkendt med vores oplysninger, og vi har vores token, er vi i stand til at gøre mange ting med dette token.
vi kunne endda oprette et tilladelsesbaseret token og videregive dette til en tredjepartsapplikation (sig en ny mobilapp, vi vil bruge), og de vil være i stand til at få adgang til vores data-men kun de oplysninger, vi tillod med det specifikke token.
fordelene ved Tokens
statsløs og skalerbar
Tokens gemmes på klientsiden. Helt statsløs og klar til at blive skaleret. Vores belastningsbalancere er i stand til at videregive en bruger til nogen af vores servere, da der ikke er nogen stats-eller sessionsoplysninger overalt.
hvis vi skulle holde sessionsoplysninger om en bruger, der var logget ind, ville det kræve, at vi fortsætter med at sende den bruger til den samme server, som de loggede ind på (kaldet session affinity).
dette medfører problemer, da nogle brugere ville blive tvunget til den samme server, og dette kunne medføre et sted med tung trafik.
ikke at bekymre dig selv! Disse problemer er væk med tokens, da token selv indeholder dataene for den pågældende bruger.
sikkerhed
tokenet, ikke en cookie, sendes på hver anmodning, og da der ikke sendes nogen cookie, hjælper dette med at forhindre CSRF-angreb. Selvom din specifikke implementering gemmer token i en cookie på klientsiden, er cookien kun en lagringsmekanisme i stedet for en autentificering. Der er ingen sessionsbaseret information at manipulere, da vi ikke har en session!
token udløber også efter et bestemt tidsrum, så en bruger skal logge ind igen. Dette hjælper os med at forblive sikre. Der er også begrebet token tilbagekaldelse, der giver os mulighed for at ugyldiggøre et specifikt token og endda en gruppe tokens baseret på det samme autorisationstilskud.
udvidelsesmuligheder (ven af en ven og tilladelser)
Tokens giver os mulighed for at opbygge applikationer, der deler tilladelser med en anden. For eksempel har vi knyttet tilfældige sociale konti til vores store dem som Facebook eller Kvidre.
når vi logger ind på Kvidre via en tjeneste (lad os sige Buffer), tillader vi Buffer at sende til vores Kvidre stream.
ved at bruge tokens giver vi selektive tilladelser til tredjepartsapplikationer. Vi kunne endda bygge vores egen API og uddele særlige tilladelsestokens, hvis vores brugere ønskede at give adgang til deres data til en anden applikation.
flere platforme og domæner
vi talte lidt om CORS tidligere. Når vores applikation og service udvides, bliver vi nødt til at give adgang til alle mulige enheder og applikationer (da vores app helt sikkert bliver populær!).
når vores API bare serverer data, kan vi også vælge design til at betjene aktiver fra en CDN. Dette eliminerer de problemer, CORS bringer op, efter at vi har indstillet en hurtig headerkonfiguration til vores applikation.
Access-Control-Allow-Origin: *vores data og ressourcer er tilgængelige for anmodninger fra ethvert domæne nu, så længe en bruger har et gyldigt token.
standardbaseret
når du opretter token, har du et par muligheder. Vi dykker mere ind i dette emne, når vi sikrer en API i en opfølgningsartikel, men standarden at bruge ville være JSON-Tokens.
denne handy debugger og bibliotek diagram viser støtte til JSON Tokens. Du kan se, at det har en stor mængde støtte på tværs af en række sprog. Dette betyder, at du faktisk kan skifte din godkendelsesmekanisme ud, hvis du vælger at gøre det i fremtiden!
konklusion
dette var bare et kig på hvordan og hvorfor af tokenbaseret godkendelse. Som det altid er tilfældet i sikkerhedsverdenen, er der meget mere til hvert emne, og det varierer pr. Vi dykker endda ind i nogle emner om skalerbarhed, som også fortjener sin egen samtale.
dette var et hurtigt overblik på højt niveau, så du er velkommen til at påpege alt, hvad der blev savnet, eller eventuelle spørgsmål, du har om sagen.
i vores næste artikel vil vi se på anatomien af JSON-Tokens.
Bemærk: tilføjelse af ACAO header info og CSRF præciseringer (tak til Emily Stark for artiklen info)