Introduksjon
Token-basert autentisering er fremtredende overalt på nettet i dag. Med de fleste webbedrifter som bruker EN API, er tokens den beste måten å håndtere autentisering for flere brukere.
det er noen svært viktige faktorer når du velger tokenbasert godkjenning for søknaden din. Hovedårsakene til tokens er:
- Statsløse og skalerbare servere
- Mobilapplikasjonsklar
- Pass godkjenning til andre programmer
- Ekstra sikkerhet
Hvem Bruker Tokenbasert Godkjenning?
enhver større API eller webapplikasjon som du har kommet over, har mest sannsynlig brukt tokens. Programmer Som Facebook, Twitter, Google+, GitHub, og så mange flere bruker tokens.
La oss ta en titt på nøyaktig hvordan det fungerer.
Hvorfor Tokens Kom Rundt
før Vi kan se hvordan token-basert autentisering fungerer og fordelene, må vi se på måten autentisering har blitt gjort tidligere.
Serverbasert Autentisering (Den Tradisjonelle Metoden)
SIDEN HTTP-protokollen er statsløs, betyr dette at hvis vi autentiserer en bruker med brukernavn og passord, så på neste forespørsel, vil vår søknad ikke vite hvem vi er. Vi må autentisere igjen.
den tradisjonelle måten å få våre applikasjoner til å huske hvem vi er, er å lagre brukerens innloggede informasjon på serveren. Dette kan gjøres på flere forskjellige måter på økten, vanligvis i minnet eller lagret på disken.
som web, applikasjoner og fremveksten av mobilapplikasjonen har kommet, har denne autentiseringsmetoden vist problemer, spesielt i skalerbarhet.
Problemene Med Serverbasert Godkjenning
det oppsto noen store problemer med denne godkjenningsmetoden.
- Økter: Hver gang en bruker er autentisert, må serveren opprette en post et sted på serveren vår. Dette gjøres vanligvis i minnet, og når det er mange brukere som autentiserer, øker overhead på serveren din.
- Skalerbarhet: siden økter er lagret i minnet, gir dette problemer med skalerbarhet. Etter hvert som våre skyleverandører begynner å replikere servere for å håndtere applikasjonsbelastning, vil det å ha viktig informasjon i øktminnet begrense vår evne til å skalere.
- KOR: Som vi ønsker å utvide vår søknad for å la våre data brukes på tvers av flere mobile enheter, må vi bekymre oss for cross-origin resource sharing (CORS). NÅR VI bruker AJAX-anrop for å hente ressurser fra et annet domene (mobil TIL VÅR API-server), kan vi få problemer med forbudte forespørsler.
- CSRF: Vi vil også ha beskyttelse mot cross-site request forfalskning (CSRF). Brukere er utsatt FOR csrf-angrep siden de allerede kan godkjennes med å si et banknettsted, og dette kan bli utnyttet når de besøker andre nettsteder.
med disse problemene var skalerbarhet den viktigste, det var fornuftig å prøve en annen tilnærming.
Hvordan Token-Basert Fungerer
Token-basert godkjenning er statsløs. Vi lagrer ikke informasjon om brukeren vår på serveren eller i en økt.
dette konseptet alene tar seg av mange av problemene med å måtte lagre informasjon på serveren.
ingen øktinformasjon betyr at søknaden din kan skalere og legge til flere maskiner etter behov uten å bekymre deg for hvor en bruker er logget inn.
selv om denne implementeringen kan variere, er kjernen i den som følger:
- Bruker Ber Om Tilgang Med Brukernavn / Passord
- Søknad validerer legitimasjon
- Søknad gir en signert token til klienten
- Klient butikker som token og sender den sammen med hver forespørsel
- Server verifiserer token og svarer med data
Hver enkelt forespørsel vil kreve token. Dette token skal sendes I HTTP-header slik at vi holder med ideen om statsløse HTTP-forespørsler. Vi må også sette vår server til å godta forespørsler fra alle domener som bruker Access-Control-Allow-Origin: *. Det som er interessant med å utpeke * i ACAO-hodet, er at det ikke tillater forespørsler om å levere legitimasjon som HTTP-godkjenning, ssl-sertifikater på klientsiden eller informasjonskapsler.
Når vi har autentisert med vår informasjon og vi har vår token, kan vi gjøre mange ting med dette token.
Vi kan til og med lage et tillatelsesbasert token og sende dette videre til et tredjepartsprogram (si en ny mobilapp vi vil bruke), og de vil kunne få tilgang til dataene våre-men bare informasjonen vi tillot med det bestemte token.
Fordelene Med Tokens
Statsløse Og Skalerbare
Tokens lagres på klientsiden. Helt statsløs og klar til å bli skalert. Våre lastbalansere kan sende en bruker til noen av våre servere, siden det ikke er noen stat eller øktinformasjon hvor som helst.
hvis vi skulle beholde øktinformasjon om en bruker som var logget inn, ville dette kreve at vi fortsetter å sende den brukeren til samme server som de logget inn på (kalt øktaffinitet).
dette bringer problemer siden noen brukere vil bli tvunget til samme server, og dette kan gi et sted med stor trafikk.
Ikke bekymre deg skjønt! Disse problemene er borte med tokens siden token selv holder dataene for den brukeren.
Sikkerhet
token, ikke en informasjonskapsel, sendes på hver forespørsel, og siden det ikke sendes noen informasjonskapsel, bidrar dette til å forhindre CSRF-angrep. Selv om din spesifikke implementering lagrer token i en informasjonskapsel på klientsiden, er informasjonskapselen bare en lagringsmekanisme i stedet for en autentisering. Det er ingen øktbasert informasjon å manipulere siden vi ikke har en økt!
token utløper også etter en viss tid, så en bruker må logge inn igjen. Dette hjelper oss å holde oss trygge. Det er også begrepet token tilbakekalling som gjør at vi kan ugyldiggjøre et bestemt token og til og med en gruppe tokens basert på samme autorisasjonstilskudd.
Utvidelsesmuligheter(Venn Av En Venn Og Tillatelser)
Tokens vil tillate oss å bygge programmer som deler tillatelser med en annen. For eksempel har vi koblet tilfeldige sosiale kontoer til våre store som Facebook eller Twitter.
når vi logger På Twitter via en tjeneste (la Oss si Buffer), tillater Vi Buffer å poste Til Vår Twitter-strøm.
ved å bruke tokens, gir vi selektive tillatelser til tredjepartsprogrammer. Vi kunne til og med bygge vår EGEN API og dele ut spesielle tillatelsestokener hvis brukerne ønsket å gi tilgang til dataene sine til et annet program.
Flere Plattformer Og Domener
vi snakket litt om CORS tidligere. Når vår søknad og tjeneste utvides, må vi gi tilgang til alle slags enheter og applikasjoner (siden vår app vil mest definitivt bli populær!).
Å ha VÅR API bare tjene data, kan vi også gjøre design valg å tjene eiendeler fra EN CDN. Dette eliminerer problemene SOM CORS bringer opp etter at vi har satt en rask header konfigurasjon for vår søknad.
Access-Control-Allow-Origin: *våre data og ressurser er tilgjengelige for forespørsler fra alle domener nå så lenge en bruker har et gyldig token.
Standardbasert
når du oppretter token, har du noen alternativer. Vi vil dykke mer inn i dette emnet når vi sikrer EN API i en oppfølgingsartikkel, men standarden som skal brukes, vil VÆRE JSON Web Tokens.
denne hendige debugger og bibliotek diagrammet viser støtte FOR JSON Web Tokens. Du kan se at den har en stor mengde støtte på tvers av en rekke språk. Dette betyr at du faktisk kan bytte ut autentiseringsmekanismen hvis du velger å gjøre det i fremtiden!
Konklusjon
Dette var bare en titt på hvordan og hvorfor av token – basert autentisering. Som det alltid er tilfelle i sikkerhetsverdenen, er det mye mer til hvert emne, og det varierer per brukstilfelle. Vi dove inn noen emner på skalerbarhet som fortjener sin egen samtale også.
Dette var en rask oversikt på høyt nivå, så vær så snill å påpeke alt som ble savnet eller spørsmål du har om saken.
i vår neste artikkel ser vi på anatomien TIL JSON Web Tokens.
Merk: Legge ACAO header info OG CSRF avklaringer (takk Til Emily Stark for artikkelen info)