Vad är JWT? En tydlig guide till JSON Web Tokens

JWT i enkla ord

En JWT (JSON Web Token) är en kompakt, URL-säker sträng som representerar en uppsättning information (vanligtvis om en användare eller session) på ett sätt som kan skickas mellan system. Du ser den ofta som ett långt värde som börjar med något i stil med eyJ..., skickat i en HTTP-header som Authorization: Bearer <token>.

Varför använda en token alls?

Traditionella inloggningar förlitar sig ofta på server-sessioner: efter att du loggar in lagrar servern sessionsdata och ger webbläsaren en session-ID-cookie. Varje förfrågan innehåller den cookien och servern slår upp sessionen.

Med tokenbaserad autentisering kan servern undvika att hålla sessionsstatus för varje användarförfrågan. Istället håller klienten en token (som en JWT) och inkluderar den i API-anrop. Detta är populärt för API:er eftersom det:

• fungerar bra över flera tjänster (API-gateways, mikrotjänster)
• passar mobil- och single-page-appar (SPA) som anropar API:er direkt
• minskar behovet av delad sessionlagring mellan servrar

Viktig nyans: “stateless” betyder inte “inga serverkontroller någonsin.” Många verkliga system validerar fortfarande tokens mot användarstatus, nyckelrotation eller återkallandemekanismer.

Autentisering vs auktorisation (enkelt språk)

• Autentisering svarar på: Vem är du? (Du loggar in och bevisar din identitet.)
• Auktorisation svarar på: Vad får du göra? (Du kan läsa fakturor, redigera projekt, komma åt admin-sidor osv.)

JWT:er brukar bära bevis på autentisering (att du är inloggad) och enklare auktorisationshintar (roller, behörigheter, scopes)—men din server bör fortfarande genomdriva auktorisationsregler.

Var JWTs dyker upp

Du ser ofta JWTs använda som access tokens i:

• webb-API:er
• SPAs
• mobilappar
• system som använder OAuth 2.0 eller OpenID Connect (OIDC)

JWT-struktur: header, payload och signature

En JWT är en kompakt sträng bestående av tre delar, var och en base64url-kodad och separerad med punkter:

header.payload.signature

Exempel (redigerat):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c…

1) Header

Headern beskriver hur token skapades—viktigast är signeringsalgoritmen (t.ex. HS256, RS256/ES256) och tokentypen.

Vanliga fält:

• typ: ofta "JWT" (brukar ignoreras i praktiken)
• alg: den signeringsalgoritm som användes
• kid: en nyckelidentifierare för att hjälpa verifieraren välja rätt nyckel vid rotation

Säkerhetsnotering: lita inte blint på headern. Inför en tillåtlistning av algoritmer du faktiskt använder, och acceptera inte alg: "none".

2) Payload

Payloaden håller “claims” (fält) om användaren och tokenkontexten: vem den är för, vem som utfärdade den och när den går ut.

Viktigt: JWTs är inte krypterade som standard. Base64url-kodning gör token URL-säker; den döljer inte data. Vem som helst som får token kan avkoda header och payload.

Därför bör du undvika att lägga hemligheter (lösenord, API-nycklar) eller känsliga personuppgifter i en JWT.

3) Signature

Signaturen skapas genom att signera header + payload med en nyckel:

• HS256: en delad hemlighet signerar och verifierar
• RS256/ES256: en privat nyckel signerar; en publik nyckel verifierar

Signaturen ger integritet: den låter servern verifiera att token inte ändrats och att den skapats av en betrodd signerare. Den ger inte konfidentialitet.

Storleksöverväganden

Eftersom en JWT inkluderar header och payload vid varje förfrågan där den skickas, innebär större tokens mer bandbredd och overhead. Håll claims slimmade och föredra identifierare framför tunga data.

Payload och claims: vad du kan (och inte bör) lagra

Claims faller generellt i två kategorier: registered (standardiserade namn) och custom (dina apps fält).

Vanliga registrerade claims

• iss (issuer): vem som skapade token
• sub (subject): vem token handlar om (ofta ett användar-id)
• aud (audience): vem token är avsedd för (t.ex. ett specifikt API)
• exp (expiration time): när token inte längre ska accepteras
• iat (issued at): när token skapades
• nbf (not before): token ska inte accepteras före denna tid

Anpassade claims: håll dem minimala

Inkludera bara vad den mottagande tjänsten verkligen behöver för att fatta ett auktorisationsbeslut.

Bra exempel:

• ett stabilt internt användar-ID (user_id)
• en liten uppsättning roller/behörigheter (endast om du kan hålla dem aktuella)
• ett tenant-/organisations-ID i multi-tenant-appar

Undvik “bekvämlighetsclaims” som duplicerar mycket profildata. De ökar tokenstorleken, blir snabbt inaktuella och ökar skadan om token läcker.

Vad du aldrig ska lägga i en JWT-payload

Eftersom payload är läsbar, lagra inte:

• lösenord, API-nycklar, refresh tokens eller andra hemliga värden
• betalningsuppgifter, personnummer eller känsliga personuppgifter
• något du inte vill ska kopieras från en webbläsare, proxy eller logg

Om du behöver känslig information, lagra den server-side och sätt endast en referens (som ett ID) i token—eller använd ett krypterat tokenformat (JWE) när det är lämpligt.

Hur signaturen fungerar (och vad den garanterar)

Signering är inte kryptering.

• Signering är som att försegla ett brev: folk kan läsa det, men de kan kontrollera att det inte ändrats.
• Kryptering är som att låsa brevet i en låda: bara den med nyckeln kan läsa det.

När en JWT utfärdas signerar servern den kodade headern + payload. När token presenteras senare, räknar servern om signaturen och jämför. Om någon ändrar ens ett tecken (t.ex. "role":"user" till "role":"admin"), misslyckas verifieringen och token avvisas.

JWT vs OAuth, OpenID Connect och token-typer

JWT är ett tokenformat. OAuth 2.0 och OpenID Connect (OIDC) är protokoll som beskriver hur appar begär, utfärdar och använder tokens.

OAuth 2.0 och access/refresh tokens

OAuth 2.0 handlar främst om auktorisation: att låta en app komma åt ett API å en användares vägnar utan att dela användarens lösenord.

• Access token: presenteras för ett API för att bevisa behörighet; kan vara en JWT eller en opak token
• Refresh token: längrelivad token som används för att få nya access tokens

Access tokens är typiskt kortlivade (minuter). Korta livstider begränsar skadan vid läckage.

OpenID Connect (OIDC) och ID-tokens

OIDC lägger till autentisering (vem användaren är) ovanpå OAuth 2.0 och introducerar en ID token, som vanligtvis är en JWT.

• ID token: för klientappen att bekräfta användarens identitet
• Access token: för API:t att auktorisera förfrågningar

En viktig regel: använd inte en ID token för att anropa ett API.

Om du vill ha mer praktisk vägledning om flöden, läs ett blogginlägg om JWT-autentiseringsflöden.

Vanligt JWT-autentiseringsflöde

Ett typiskt flöde ser ut så här:

1) Inloggning

Användaren loggar in (e-post/lösenord, SSO osv.). Om det lyckas skapar servern en JWT (ofta en access token) med viktiga claims som subject och expiration.

2) Tokenutfärdande

Servern signerar token och returnerar den till klienten (webbapp, mobilapp eller annan tjänst).

3) API-anrop

För skyddade endpoints inkluderar klienten JWT i Authorization-headern:

Authorization: Bearer <JWT>

4) Verifiering

Innan förfrågan hanteras, kontrollerar API:t vanligen:

• signatur (integritet + betrodd utgivare)
• exp (inte utgången)
• iss (förväntad utgivare)
• aud (avsedd för detta API)

Om alla kontroller passerar behandlas användaren som autentiserad och auktorisationsregler tillämpas (t.ex. postnivå-behörigheter).

5) En snabb not om klockskift

Eftersom systemklockor kan driva, tillåter många system ett litet klockskift när man validerar tidsbaserade claims som exp (och ibland nbf). Håll skiftet litet för att undvika att förlänga token-gyldigheten mer än avsett.

Var man lagrar JWTs säkert

Val av lagring förändrar vad angripare kan stjäla och hur lätt de kan återanvända en token.

Webbläsarappar: minne vs localStorage vs cookies

Minnesslagring (ofta rekommenderat för SPAs) håller access token i JS-state. Den rensas vid uppdatering och minskar risken för att token "plockas upp senare", men en XSS-bugg kan fortfarande läsa den medan sidan körs. Kombinera med kortlivade access tokens och ett refresh-flöde.

localStorage/sessionStorage är enkelt men riskabelt: alla XSS-sårbarheter kan exfiltrera tokens från webbläsarlagring. Om du använder dem, gör XSS-förebyggande icke-förhandlingsbart (CSP, escape av output, dependency-hygien) och håll tokens kortlivade.

Säkra cookies (ofta det säkraste standardvalet för webben) lagrar tokens i en HttpOnly-cookie så att JavaScript inte kan läsa dem—vilket minskar effekten av XSS-stöld. Trade-off är CSRF-risk, eftersom webbläsaren bifogar cookies automatiskt.

Om du använder cookies, ställ in:

• HttpOnly
• Secure (endast HTTPS)
• SameSite=Lax eller SameSite=Strict (vissa cross-site-flöden kan behöva SameSite=None; Secure)

Överväg även CSRF-tokens för state-ändrande förfrågningar.

Mobilappar: föredra OS säker lagring

På iOS/Android, lagra tokens i plattformsäker lagring (Keychain / Keystore-backed storage). Undvik vanliga filer eller preferenser. Om ditt hotmodell inkluderar rootade/jailbreakade enheter, anta att extraktion är möjlig och lita på kortlivade tokens och serverkontroller.

Minsta privilegier

Begränsa vad en token kan göra: använd minimala scopes/claims, håll access tokens kortlivade och undvik att bädda in känslig data.

Vanliga JWT-säkerhetsfällor att undvika

JWTs är bekväma, men många incidenter uppstår från förutsägbara misstag. Behandla en JWT som kontanter: den som får den kan ofta spendera den.

1) Alltför långa utgångstider

Om en token varar i dagar eller veckor ger ett läckage en angripare hela den perioden.

Föredra kortlivade access tokens (minuter) och förnya dem via en säkrare mekanism. Om du behöver “kom ihåg mig”, gör det med refresh tokens och server-side-kontroller.

2) Hoppa över issuer- och audience-kontroller

Giltiga signaturer räcker inte. Verifiera iss och aud, och validera tidsbaserade claims som exp och nbf.

3) Lita inte på avkodad payload

Avkodning är inte verifiering. Verifiera alltid signaturen på servern och genomdriv behörigheter på serversidan.

4) Algoritmförvirring och nyckelblandning

• Acceptera inte vilken algoritm token påstår. Ha en tillåtlistning av förväntade algoritmer.
• Blanda inte symmetriska nycklar (HS256) med publika/privata nycklar (RS256/ES256).
• Minimera blast radius genom att separera nycklar per miljö och rotera dem.

5) Tokenläckage via URL:er, loggar och referrers

Undvik att lägga JWTs i query-parametrar. De kan hamna i webbläsarhistorik, serverloggar, analysverktyg och referrer-headers.

Använd istället Authorization: Bearer ....

6) Ingen plan för nyckelrotation eller återkallelse

Anta att nycklar och tokens kan läcka. Rotera signeringsnycklar, använd kid för att stödja smidig rotation och ha en återkallelseplan (korta utgångstider + möjlighet att inaktivera konton/sessioner). För rekommendationer om lagring, läs ett blogginlägg om var man säkert lagrar JWT.

När använda JWT (och när inte)

JWTs är användbara, men inte alltid det bästa valet. Frågan är om du tjänar på en självständig token som kan verifieras utan databasuppslag vid varje förfrågan.

Passar bra för JWT

• Stateless API:er i skala: lokal verifiering (signatur + expiry) utan per-förfrågan sessionsuppslag
• Flera tjänster / mikrotjänster: delade verifieringsregler och publika nycklar
• SPAs och mobilappar: klienter som anropar API:er direkt
• Kortlivade access tokens: minskad skada vid stöld

När JWT är ett dåligt val

• Omedelbar återkallelse krävs: sessions är enklare om du behöver ”logga ut överallt nu” utan extra infrastruktur
• Du behöver bära känslig data: vanliga JWTs är signerade, inte krypterade
• Långlivade tokens: de är högvärdiga och lockar till stöld

När enkla sessioncookies är bättre

För traditionella serverrenderade webbappar där enkel ogiltigförklaring är viktig, är server-side sessions med HttpOnly-cookies ofta ett enklare och säkrare standardval.

Snabb beslutschecklista

Välj JWT om du behöver stateless verifiering över tjänster och kan hålla tokens kortlivade.

Undvik JWT om du behöver omedelbar återkallelse, planerar att lagra känslig data i token eller kan använda sessionscookies utan friktion.

Praktisk checklista och vanliga frågor

Verifieringschecklista (vad man ska kontrollera varje gång)

1. Signaturen är giltig

Verifiera med rätt nyckel och förväntad algoritm. Avvisa ogiltiga signaturer—inga undantag.

2. exp (expiration)

Säkerställ att token inte har gått ut.

3. nbf (not before)

Om det finns, säkerställ att token inte används för tidigt.

4. aud (audience)

Bekräfta att token var menad för ditt API/tjänst.

5. iss (issuer)

Bekräfta att token kom från förväntad utgivare.

6. Sanity checks (rekommenderat)

Validera tokenformat, införa maxstorlek och avvisa oväntade claim-typer för att minska kantfallsbuggar.

Välja HS256 vs RS256/ES256

• HS256 (symmetrisk nyckel): en delad hemlighet signerar och verifierar.

  • Passar för: en enda app/API kontrollerad av ett team.
  • Akta dig för: varje verifierare som har hemligheten kan också skapa tokens.

• RS256 / ES256 (asymmetriska nycklar): privat nyckel signerar; publik nyckel verifierar.

  • Passar för: flera tjänster som verifierar tokens; distribuera publika nycklar utan att ge signeringsrätt.
  • Driftanteckning: rotation är ofta säkrare eftersom endast signeraren håller den privata nyckeln.

Tumregel: om mer än ett oberoende system behöver verifiera tokens (eller du inte litar fullt ut på varje verifierare), föredra RS256/ES256.

Övervakning och loggning (utan att läcka tokens)

• Logga inte råa tokens (headers, cookies, query-strängar).
• Om du behöver korrelation, logga ett token-fingeravtryck (t.ex. en hash) eller säker metadata (iss, aud, och ett användar-ID endast om policyn tillåter).
• Bevaka anomalier: signaturfel, toppar i utgångna tokens, ovanliga audiences/issuers och misstänkta refresh-mönster.

Vanliga frågor

Är JWT krypterad?

Inte som standard. De flesta JWTs är signerade, inte krypterade, vilket betyder att innehållet kan läsas av vem som helst som har token. Använd JWE eller håll känslig data utanför JWTs.

Kan jag återkalla en JWT?

Inte enkelt om du förlitar dig bara på självständiga access tokens. Vanliga tillvägagångssätt inkluderar kortlivade access tokens, svartlistor för högrisk-händelser eller refresh tokens med rotation.

Hur lång bör exp vara?

Så kort som din UX och arkitektur tillåter. Många API:er använder minuter för access tokens, i kombination med refresh tokens för längre sessions.

Bygg JWT-skyddade appar snabbare med Koder.ai

Om du implementerar JWT-auth i en ny API eller SPA är mycket av arbetet repetitivt: koppla middleware, validera iss/aud/exp, sätta cookie-flaggor och hålla tokenhantering utanför loggar.

Med Koder.ai kan du snabba upp utvecklingen av en webbapp (React), backendtjänster (Go + PostgreSQL) eller en Flutter-mobilapp via ett chattdrivet arbetsflöde—sedan iterera i ett planeringsläge, använda snapshots och rollback medan du förfinar säkerheten, och exportera källkoden när du är redo. Det är ett praktiskt sätt att accelerera byggandet av JWT-baserade autentiseringsflöden samtidigt som du behåller kontroll över verifieringslogik, nyckelrotationsstrategi och driftsättningsinställningar (inklusive custom domains).