Token-baserad autentisering är ett protokoll som gör att användare kan verifiera sin identitet och i retur få ett unikt åtkomst-token. Under tiden som detta token är giltigt kan användaren komma åt den webbplats eller app som detta token har utfärdats för istället för att behöva ange inloggningsdata varje gång man går tillbaka till samma webbplats, app eller annan resurs som skyddas av samma token.

Autentiserings-token fungerar som en stämplad biljett. Användaren får tillgång så länge som detta token är giltigt. När användaren loggar ut eller avslutar en app blir detta token ogiltigt.

Token-baserad autentisering skiljer sig från traditionell lösenords-baserad eller server-baserad autentisering. Ett token ger ett andra säkerhetsskikt och administratörer har detaljerad kontroll över varje aktion eller transaktion.

Men användning av ett token kräver lite kännedom om kodning. De flesta utvecklare lär sig snabbt tekniken men det finns en inlärningskurva.

Låt oss titta närmare på detta så att du kan avgöra om token passar dig och din organisation. 

En historia om autentiserinds-token

Autentisering och auktorisering är olika begrepp men de har en del gemensamt. Innan vi hade autentiserings-token fanns bara lösenord och servers. Vi använde traditionella metoder för att se till att rätt personer kunde komma åt rätt saker på rätt tid. Det var inte alltid effektivt.

Tänk på lösenord. De måste normalt:

• Skapas. Någon måste sätta samman en kombination av bokstäver, siffror och symboler.
• Minnas. Den som har lösenordet måste komma ihåg den unika kombinationen.
• Repeteras. Så fort användaren vill komma åt något måste lösenordet anges.

Stöld av lösenord är vanligt.Ett av de första dokumenterade fallet där ett lösenord stals inträffade redan 1962. Många kan inte komma ihåg sina lösenord och använder därför tricks såsom:

• Skriva ner dem. Papperslappar fyllda med lösenord är en säkerhetsmässig mardröm.
• Repetera dem. Många använder samma lösenord på flera ställen. Om ett sådant lösenord avslöjas så är många konton sårbara.
• Göra små förändringar av dem. Man kan ändra en bokstav eller siffra när man ombeds att uppdatera ett lösenord.

Lösenord kräver också autentisering i en server. Varje gång man loggar in skapar datorn en post för transaktionen. Behovet av minne ökar i takt med det.

Token-autentisering är annorlunda.

Med token-autentisering verifieras en server-förfrågan av en sekundär tjänst. När verifikationen är klar utfärdar servern ett token och svarar på förfrågan.

Användaren måste kanske fortfarande komma ihåg ett lösenord men ett token ger en annan typ av åtkomst som är mycket svårare att komma över. Och sessionens poster tar inte upp utrymme på servern. 

3 Typer av autentiserings-token

Alla autentiserings-token ger åtkomst men varje typ fungerar lite olika.

Det finns tre typer av auktoriserings-token:

• Ansluten: Nycklar, skivor, lagringsenheter och andra fysiska system ansluts till systemet för åtkomst. Om du använt en USB-enhet eller ett smartcard för att logga in på ett system så har du använt ett anslutet token.
• Kontaktlös: En enhet är tillräckligt nära för att kommunicera med servern men den kopplas inte in. Microsofts så kallade "magiska ring" är ett exempel på denna typ av token.
• Ej ansluten: En enhet kan kommunicera med servern på långt håll även om den inte har någon kontakt alls med en annan enhet. Om du har använt din telefon i en två-faktor-autentisering så har du använt denna typ av token.

I alla tre fallen måste användaren göra något för att starta processen. De behöver kanske ange ett lösenord eller svara på en fråga. Men även om de utfört dessa preliminära steg perfekt så kan de inte få åtkomst utan hjälp från ett åtkomst-token. 

Token-autentisering i 4 enkla steg

Använd ett token-baserat system för autentisering så behöver besökares inloggningsdata bara verifieras en gång. I retur får de ett token som ger åtkomst under den tidperiod som du definierat.

Processen fungerar så här:

• Förfrågan: Personen ber om åtkomst av en server eller en skyddad resurs. Det kan involvera inloggning med ett lösenord eller någon annan process som du har specificerat.
• Verifiering: Servern avgör om den personen ska få åtkomst. Det kan vara kontroll av lösenord och användarnamn eller annan process som du har specificerat.
• Token: Servern kommunicerar med anordningen för autentisering såsom en ring, nyckel, telefon eller liknande enhet. Efter verifiering utfärdar servern ett token som skickas till användaren.
• Lagring: Detta token finns i användarens webbläsare medan arbetet fortskrider.

Om användaren besöker en annan del av servern så kommunicerar detta token igen med servern. Åtkomst godkänns eller nekas beroende på detta token.

Administratörer sätter gränserna för token. Du kan tillåta engångs-token som förstörs direkt när personen loggar ut. Eller du kan ställa in det så det förstörs efter en specificerad tid.

JWT (JSON Web Token): En särskild sorts autentiserings-token

Eftersom så många användare numer ansluter via mobiltelefoner (appar) och webb-appar behöver utvecklare ett säkert sätt att autentisera som är lämpligt för dessa plattformar.

För att lösa den utmaningen använder många utvecklare JWT (JSON Web Token) när de arbetar med token för sina appar.

JWT är en öppen standard. Slutprodukten är en säker och skyddad kommunikation mellan två parter. Data verifieras med en digital signatur och om den skickas via HTTP skyddas data med kryptering.
 

JWT består av tre viktiga komponenter.

1. Header: Definierar typ av token och använd signatur-algoritm.
2. Innehåll: Definierar utfärdare av token, dess giltighetstid med mera.
3. Signatur: Verifierar att meddelandet inte har ändrats under överföringen med en säker signatur.

Kodning knyter samman dessa delar.Slutprodukten kan se ut så här.

Låt dig inte skrämmas av JSON-kod. Denna typ av notation är vanlig när olika instanser vill skicka data fram och tillbaka då referenser finns. Om du är intresserad av att använda JWT men aldrig tidigare stött på språket så kan en resurs som denna hjälpa dig.

Fördelar och nackdelar med JWT

JWT har många fördelar.

• Storlek: Token skrivna med detta programspråk är kompakta och de kan utväxlas mellan två instanser ganska snabbt.
• Enkelhet: Token kan genereras från nästan var som helst och de behöver inte verifieras i din server.
• Kontroll: Du kan specificera vad åtkomsten gäller, hur länge godkännandet gäller och vad som får göras medan användaren är inloggad.

Det finns också potentiella nackdelar,

• En nyckel: JWT förlitar sig på en nyckel. Om den nyckeln läcker ut så blir hela systemet sårbart.
• Komplexitet: Dessa token är inte enkla att förstå. Om en utvecklare inte har goda kunskaper om kryptografiska signatur-algoritmer så kan de av misstag utsätta systemet för risk.
• Begränsningar: Du kan inte trycka ut meddelanden till alla klienter och du kan inte hantera klienter från serversidan.

Varför prova autentiserings-token?

Du har utvärderat din nuvarande strategi och tror att allt är under kontroll. Varför skulle autentiserings-token bli en del av dina system? Mycket påtagliga fördelar visar sig för utvecklare som tar det språnget.

Autentiserings-token är bra för systemadministratörer som:

• Ofta beviljar tillfällig åtkomst. Din användarbas fluktuerar med datum, tid och särskilda händelser. Att bevilja och återkalla åtkomst är arbetsamt. Token kan hjälpa dig.

  Administratörer på exempelvis universitetsbibliotek skulle uppskatta införandet av token.

• Krav på finmaskig åtkomst. Din server beviljar åtkomst baserat på särskilda dokumentegenskaper, inte användaregenskaper. Lösenord ger inte möjlighet för sådan detaljrikedom.

  Tänk dig att du t.ex. driver en online-tidskrift. Du vill att alla ska läsa och kommentera bara ett dokument, inte andra. Token kan göra det möjligt.

• Primära mål för hackare. Din server innehåller känsliga dokument som skulle kunna allvarligt skada ditt företag om de kom ut. Ett enkelt lösenord ger inte tillräckligt skydd.Lite maskinvara hjälper dig en bra bit.

Det finns många fler exempel på användning av autentiserings-token. Men denna enkla lista kan ge dig idéer och ju mer du tänker på fördelarna, desto mer sannolikt är det att du kommer med på tåget. 

Håll dig till bästa praxis för autentiserings-token

Autentiserings-token är tänkta att förstärka dina säkerhetsprotokoll och skydda din server. Men de fungerar bara effektivt om du har byggt dina processer på säkerhet.

Ditt autentiserings-token ska vara:

• Privat. Användare kan inte dela enheter för token-autentisering eller skicka dem mellan olika avdelningar. Precis som med lösenord får de inte delas med andra delar av ditt säkerhetssystem.
• Säkert. Kommunikation mellan token och server måste ske säkert via HHTPS-anslutningar. Kryptering är central för att hålla token skyddade.
• Testat. Gör regelbundna tester av token för att kontrollera att ditt system är säkert och fungerar som det ska. Om du stöter på problem så åtgärda det omedelbart.
• Lämpligt. Välj rätt sorts token för dina enskilda användarfall. JWT är exempelvis inte lämpliga som sessions-token. De kan vara kostsamma och de säkerhetsrisker som uppkommer är går inte att eliminera. Se till att alltid välja rätt verktyg för jobbet.

Var noggrann innan du fattar beslut om autentiserings-token. Gör läxan, fråga kollegor och se till att du gör ditt bästa för ditt företag. 

Låt oss hjälpa dig

När vi funderar på hur vi ska kunna få säker åtkomst både hemma och på kontoret så är det lika viktigt att implementera mekanismer såsom token-baserad autentisering för att garantera att bara rätt att personer har tillgång till våra digitala resurser.

Se hur Okta kan förbättra din säkerhet.

Referenser

The World's First Computer Password? It Was Useless Too, (januari 2012).Wired.

Microsoft Says This Magic Ring Could Make Passwords Obsolete, (juni 2020). Small Business Trends.

JSON Web Token, (maj 2015). Internet Engineering Task Force.

Working With JSON. Mozilla.

Security Token. Citi.

Security Token Definition, (juni 2020). Investopedia.

Two-Factor Authentication, (februari 2020). Explain That Stuff.

When Are Tokens Securities? Some Questions from the Perplexed, (december 2018). Harvard Law School Forum on Corporate Governance.