Ins och Outs av tokenbaserad autentisering

introduktion

tokenbaserad autentisering är framträdande överallt på webben idag. Med de flesta webbföretag som använder ett API är tokens det bästa sättet att hantera autentisering för flera användare.

det finns några mycket viktiga faktorer när du väljer tokenbaserad autentisering för din applikation. De främsta orsakerna till tokens är:

• statslösa och skalbara servrar
• mobilapplikation redo
• skicka autentisering till andra applikationer
• Extra säkerhet

Vem använder tokenbaserad autentisering?

alla större API eller webbapplikationer som du har stött på har troligtvis använt tokens. Applikationer som Facebook, Twitter, Google+, GitHub och så många fler använder tokens.

Låt oss ta en titt på exakt hur det fungerar.

varför Tokens kom runt

innan vi kan se hur tokenbaserad autentisering fungerar och dess fördelar måste vi titta på hur autentisering har gjorts tidigare.

serverbaserad autentisering (den traditionella metoden)

eftersom HTTP-protokollet är statslöst betyder det att om vi autentiserar en användare med ett användarnamn och lösenord, då på nästa begäran, kommer vår ansökan inte att veta vem vi är. Vi måste autentisera igen.

det traditionella sättet att få våra applikationer att komma ihåg vem vi är är att lagra användarinloggad information på servern. Detta kan göras på några olika sätt på sessionen, vanligtvis i minnet eller lagras på disken.

eftersom webben, applikationerna och ökningen av mobilapplikationen har uppstått har denna autentiseringsmetod visat problem, särskilt i skalbarhet.

problemen med serverbaserad autentisering

några stora problem uppstod med denna autentiseringsmetod.

• sessioner: Varje gång en användare autentiseras måste servern skapa en post någonstans på vår server. Detta görs vanligtvis i minnet och när det finns många användare autentisering, overhead på din server ökar.
• skalbarhet: eftersom sessioner lagras i minnet ger detta problem med skalbarhet. När våra molnleverantörer börjar replikera servrar för att hantera applikationsbelastning, kommer viktig information i sessionsminnet att begränsa vår förmåga att skala.
• CORS: Eftersom vi vill utöka vår applikation för att låta våra data användas över flera mobila enheter, måste vi oroa oss för resursdelning mellan ursprung (CORS). När vi använder AJAX-samtal för att ta resurser från en annan domän (mobil till vår API-server) kan vi stöta på problem med förbjudna förfrågningar.
• CSRF: vi kommer också att ha skydd mot cross-site request forgery (CSRF). Användare är mottagliga för CSRF-attacker eftersom de redan kan autentiseras med en bankwebbplats och detta kan utnyttjas när de besöker andra webbplatser.

med dessa problem, skalbarhet är den viktigaste, det var vettigt att prova ett annat tillvägagångssätt.

hur tokenbaserade verk

tokenbaserad autentisering är statslös. Vi lagrar inte någon information om vår användare på servern eller i en session.

detta koncept ensam tar hand om många av problemen med att behöva lagra information på servern.

ingen sessionsinformation innebär att din applikation kan skala och lägga till fler maskiner efter behov utan att oroa dig för var en användare är inloggad.

även om denna implementering kan variera är kärnan i den följande:

1. användare begär åtkomst med Användarnamn / Lösenord
2. ansökan validerar referenser
3. ansökan ger en signerad token till klienten
4. klient lagrar den token och skickar den tillsammans med varje begäran
5. Server verifierar token och svarar med data

varje enskild begäran kommer att kräva token. Denna token ska skickas i HTTP-rubriken så att vi håller med tanken på statslösa HTTP-förfrågningar. Vi måste också ställa in vår server för att acceptera förfrågningar från alla domäner med Access-Control-Allow-Origin: *. Det som är intressant med att ange * i Acao-rubriken är att det inte tillåter förfrågningar att tillhandahålla referenser som HTTP-autentisering, SSL-certifikat på klientsidan eller cookies.

när vi har autentiserat med vår information och vi har vår token kan vi göra många saker med denna token.

vi kan till och med skapa ett tillståndsbaserat token och vidarebefordra detta till en tredjepartsapplikation (säg en ny mobilapp som vi vill använda), och de kommer att kunna få tillgång till våra data-men bara den information som vi tillät med den specifika token.

fördelarna med Tokens

statslösa och skalbara

Tokens lagras på klientsidan. Helt statslös och redo att skalas. Våra lastbalanserare kan skicka en användare till någon av våra servrar eftersom det inte finns någon stat eller sessionsinformation någonstans.

om vi skulle behålla sessionsinformation om en användare som var inloggad, skulle detta kräva att vi fortsätter att skicka den användaren till samma server som de loggade in på (kallad session affinity).

detta medför problem eftersom vissa användare skulle tvingas till samma server och detta kan leda till en plats med tung trafik.

oroa dig inte! Dessa problem är borta med tokens eftersom själva token innehåller data för den användaren.

säkerhet

token, inte en cookie, skickas på varje begäran och eftersom det inte finns någon cookie som skickas, hjälper detta till att förhindra CSRF-attacker. Även om din specifika implementering lagrar token i en cookie på klientsidan, är cookien bara en lagringsmekanism istället för en autentisering. Det finns ingen sessionsbaserad information att manipulera eftersom vi inte har en session!

token löper också ut efter en viss tid, så en användare måste logga in igen. Detta hjälper oss att hålla oss säkra. Det finns också begreppet token-återkallande som gör att vi kan ogiltigförklara ett specifikt token och till och med en grupp tokens baserat på samma auktoriseringsbidrag.

utökningsbarhet (vän till en vän och behörigheter)

Tokens tillåter oss att bygga applikationer som delar behörigheter med en annan. Till exempel har vi länkat slumpmässiga sociala konton till våra stora som Facebook eller Twitter.

när vi loggar in på Twitter via en tjänst (låt oss säga buffert) tillåter vi buffert att posta till vår Twitter-ström.

genom att använda tokens tillhandahåller vi selektiva behörigheter till tredjepartsapplikationer. Vi kunde till och med bygga vårt eget API och dela ut speciella behörighetstoken om våra användare ville ge tillgång till sina data till en annan applikation.

flera plattformar och domäner

vi pratade lite om CORS tidigare. När vår applikation och service expanderar måste vi ge tillgång till alla typer av enheter och applikationer (eftersom vår app definitivt kommer att bli populär!).

med vårt API bara betjäna data kan vi också göra designvalet för att betjäna tillgångar från ett CDN. Detta eliminerar de problem som CORS tar upp efter att vi har ställt in en snabbhuvudkonfiguration för vår applikation.

Access-Control-Allow-Origin: *

våra data och resurser är tillgängliga för förfrågningar från alla domäner nu så länge en användare har en giltig token.

standardbaserad

när du skapar token har du några alternativ. Vi kommer att dyka mer in i det här ämnet när vi säkrar ett API i en uppföljningsartikel, men standarden att använda skulle vara JSON Web Tokens.

denna behändiga debugger och bibliotek diagram visar stöd för JSON Web Tokens. Du kan se att det har en stor mängd stöd på olika språk. Det betyder att du faktiskt kan byta ut din autentiseringsmekanism om du väljer att göra det i framtiden!

slutsats

detta var bara en titt på hur och varför tokenbaserad autentisering. Som alltid är fallet i säkerhetsvärlden finns det mycket mer i varje ämne och det varierar per användningsfall. Vi dyker till och med in i några ämnen om skalbarhet som också förtjänar sin egen konversation.

detta var en snabb överblick på hög nivå, så var god och påpeka allt som missades eller eventuella frågor du har i frågan.

i vår nästa artikel kommer vi att titta på anatomin hos JSON Web Tokens.

Obs: lägga ACAO header info och CSRF förtydliganden (tack vare Emily Stark för artikeln info)