JWT vs session: vilken autentiseringsmekanism ska du välja?

Att autentisera en användare innebär att vid varje begäran veta vem hen är. Två stora familjer ställs mot varandra: serversessioner, där servern håller reda på den inloggade användaren, och JSON Web Tokens (JWT), där identiteten färdas i en signerad token som bärs av klienten. Valet påverkar säkerheten, förmågan att skala upp och hur enkelt det är att logga ut en användare. Så här avgör du utifrån din kontext.

Serversessioner (stateful)

Med en session skapar servern en sessionsidentifierare vid inloggning, lagrar tillhörande data (identitet, roller, varukorg) på serversidan (minne, Redis, databas) och skickar tillbaka en cookie till webbläsaren som bara innehåller denna identifierare. Vid varje begäran läser servern cookien, hittar sessionen och vet vem som talar.

• Tillstånd på serversidan: sanningskällan finns kvar på servern, klienten bär endast en ogenomskinlig referens.
• Omedelbar återkallelse: att ta bort sessionen på serversidan loggar ut användaren omedelbart.
• Cookie: skickas automatiskt av webbläsaren, helst som HttpOnly, Secure och SameSite.

JSON Web Tokens (stateless)

En JWT är en självbärande token som består av tre delar kodade i base64url och åtskilda av punkter: ett header, en payload (claims, till exempel användaridentifierare och utgång) och en signatur. Servern signerar token vid inloggning; därefter räcker det att verifiera signaturen för att lita på innehållet, utan att lagra något.

• Tillståndslös: all nödvändig information finns i token, servern behöver inget delat minne.
• Verifierbar överallt: vilken tjänst som helst som känner till nyckeln kan validera token, praktiskt för distribuerade arkitekturer och SSO.
• Verktyg: du kan inspektera en token med vår JWT-avkodare, kontrollera dess signatur med JWT-verifieraren eller skapa en med JWT-generatorn.

Jämförelsetabell

Säkerhet: XSS, CSRF och återkallelse

Båda metoderna är säkra om de implementeras väl, men deras risker skiljer sig åt.

• XSS: en sessionscookie med HttpOnly är otillgänglig för JavaScript och därmed skyddad mot stöld via injektion. En JWT som lagras i localStorage är däremot läsbar av vilket skript som helst, vilket gör den till ett tacksamt mål. Att lagra JWT i en HttpOnly-cookie upphäver denna fördel med JWT men återinför CSRF-risken.
• CSRF: cookies skickas automatiskt och är därför sårbara för CSRF utan skydd (attributet SameSite, anti-CSRF-token). En JWT som skickas manuellt i Authorization-huvudet berörs inte.
• Återkallelse: detta är JWT:s svaga punkt. Eftersom den är självbärande kan den inte ogiltigförklaras före sin utgång utan att återinföra ett servertillstånd (återkallelselista, svartlista). En session tas bort omedelbart.

Skalbarhet och arkitektur

På en enda server är sessioner triviala. Så snart du fördelar lasten över flera instanser måste varje instans ha åtkomst till sessionerna: det krävs ett delat lager (Redis) eller sticky sessions. JWT lyser här, eftersom vilken instans som helst validerar token utan nätverksanrop eller gemensam lagring.

• Mikrotjänster: en JWT sprider identiteten från en tjänst till en annan utan central databas.
• Publika och mobila API:er: JWT undviker hanteringen av cookies på den nativa klientsidan.
• Klassisk monolit: sessionen förblir enklare och säkrare som standard.

När du ska välja det ena eller andra

Välj sessioner när

• Du utvecklar en klassisk webbapplikation med rendering på servern
• Omedelbar återkallelse är kritisk (bank, hälsa, backoffice)
• Du vill ha den säkraste lösningen som standard, med minst fallgropar
• Din infrastruktur klarar ett delat sessionslager utan problem

Välj JWT när

• Du exponerar ett API som konsumeras av SPA:er, mobil eller tredje part
• Du har en mikrotjänstarkitektur eller SSO mellan domäner
• Du måste skala horisontellt utan delat lager
• Du accepterar att hantera kort utgång och förnyelse av tokens

Rekommendation

För de flesta webbapplikationer förblir serversessioner det säkraste och enklaste valet: omedelbar återkallelse, HttpOnly-cookie och ingen tokenhantering på klientsidan. Spara JWT för fall där dess tillståndslöshet ger ett verkligt värde: stateless API, mobil, mikrotjänster, SSO.

Om du väljer JWT, behåll en kort livslängd (några minuter) kombinerad med en refresh token som lagras i en HttpOnly-cookie, och förbered en återkallelselista för känsliga fall. Då kombinerar du det bästa av båda världar.

Vanliga frågor