Tools Blog

Vad är en JWT? Förstå JSON Web Tokens och Stateless Auth

JSON Web Tokens Architecture

När du loggar in på en modern Single Page Application (som React eller Vue) eller en mobilapp behöver servern ett sätt att komma ihåg vem du är. Traditionellt gjorde den detta genom att lagra ett "sessions-ID" i en massiv databas på servern och släppa en cookie i din webbläsare. Varje gång du klickade på en knapp var servern tvungen att leta upp det ID:t i sin databas. Detta kallas tillståndsfull autentisering.

Men i en tid präglad av mikrotjänster och molnskalning blev databaser en flaskhals. För att lösa detta antog utvecklare Stateless Authentication via JSON Web Tokens (JWT). Med JWT behöver servern inte komma ihåg vem du är – din webbläsare talar om för servern exakt vem du är och använder kryptografi för att bevisa det.

🎥 Utbildningsvideo: Hur JWT-kryptering fungerar (Platshållare för inbäddad YouTube-konceptuell handledning)

Anatomin hos en JWT

Om du inspekterar nätverkstrafik efter att ha loggat in i en modern app, kommer du sannolikt att se en "Authorization: Bearer"-rubrik följt av en lång, slumpmässigt utseende teckensträng åtskilda av två punkter. Det är en JWT.

En JWT består av exakt tre delar: Header.Payload.Signature.

1. Rubriken

Den första delen är ett Base64URL-kodat JSON-objekt som helt enkelt beskriver token. Den innehåller vanligtvis två egenskaper: typen av token (JWT) och signeringsalgoritmen som används (som HMAC SHA256 eller RSA).

2. Nyttolasten (anspråk)

Den mellersta delen är också ett Base64URL-kodat JSON-objekt. Det är här den faktiska datan bor. Dessa uppgifter kallas "fordringar". Det kan till exempel innehålla ditt användar-ID, din roll (t.ex. "Admin") och en tidsstämpel för utgången. Eftersom denna nyttolast är kopplad till varje begäran vet servern omedelbart vem du är utan att fråga en databas.

KRITISK VARNING: Nyttolasten är bara kodad, inte krypterad. Alla som fångar upp en JWT kan enkelt avkoda den och läsa nyttolasten. Förvara aldrig lösenord, personnummer eller känslig data i en JWT-nyttolast.

3. Signaturen

Om någon kan läsa och redigera nyttolasten, vad hindrar en illvillig användare från att ändra sin roll från "Användare" till "Admin"? Svaret är signaturen.

För att skapa signaturen tar servern headern, nyttolasten och en mycket säker hemlig nyckel (endast känd för servern) och kör dem genom en kryptografisk algoritm (som SHA256). Den resulterande hashen blir signaturen.

När servern får tillbaka en token från klienten, räknar den om signaturen med hjälp av dess hemliga nyckel. Om användaren manipulerade nyttolasten (även genom att ändra en enda bokstav), kommer den omräknade signaturen inte att matcha signaturen på token, och servern kommer omedelbart att avvisa begäran som bedräglig.

Inspektera tokens på ett säkert sätt

Behöver du läsa nyttolasten för en JWT för att felsöka din applikation? Använd vår offline JWT-avkodare för att inspektera anspråken direkt utan att skicka din känsliga token till en fjärrserver.

Öppna JWT Decoder

Varför mikrotjänster älskar JWT

Föreställ dig ett företag som Netflix. De har en autentiseringsserver, en videoströmningsserver och en faktureringsserver. Om de använde traditionella sessioner skulle varje enskild server ständigt behöva kommunicera med en central databas för att kontrollera om en användare är inloggad.

Med JWTs signerar autentiseringsservern token med en privat nyckel. Användaren skickar sedan token direkt till videoservern. Eftersom videoservern har den publika nyckeln kan den självständigt verifiera signaturen. Videoservern vet exakt vem användaren är utan att någonsin prata med autentiseringsservern eller en databas. Detta gör att infrastrukturen kan skalas i det oändliga utan flaskhalsar.

The Dark Side: Token Invalidation

JWT är inte perfekta. Deras största styrka (att vara statslös) är också deras största svaghet. Eftersom servern inte registrerar aktiva tokens kan du inte enkelt logga ut en användare eller ogiltigförklara en specifik token innan den löper ut.

Om en hacker stjäl en användares JWT har hackaren full åtkomst tills tokens utgångstidsstämpel tar slut. För att minska denna risk använder säkerhetsingenjörer ett system med två token:

  • Åtkomsttokens: Kortlivade JWT (t.ex. 15 minuter) som används för API-förfrågningar.
  • Uppdatera tokens: Långlivade, stateful tokens lagrade säkert, används strikt för att begära nya åtkomsttokens. Om ett konto äventyras återkallar servern Refresh Token, och hackarens Access Token kommer naturligtvis att dö inom 15 minuter.

Vanliga frågor (FAQ)

Var ska jag lagra en JWT på frontend?

Att lagra JWTs i localStorage gör dem sårbara för Cross-Site Scripting (XSS)-attacker. Den säkraste platsen att lagra en JWT i en webbläsare är inuti en HttpOnly-cookie, som hindrar JavaScript från att komma åt den.

Vad händer om min servers hemliga nyckel läcker?

Katastrof. Om en hackare får din hemliga HMAC-nyckel eller privata RSA-nyckel kan de generera giltiga JWTs med vilken nyttolast de vill. De kan skapa tokens som ger sig själva "Super Admin"-privilegier och din server skulle acceptera dem som giltiga. Du måste rotera dina nycklar omedelbart.

Är JWT snabbare än sessionscookies?

Inte nödvändigtvis. JWT:er är betydligt större i filstorlek än ett sessions-ID på 32 tecken, vilket innebär att de förbrukar mer nätverksbandbredd på varje begäran. Deras hastighetsfördel kommer helt och hållet från att kringgå databasuppslagningar på backend.