17 okt. 2025·5 min
Vad är JWT? En tydlig guide till JSON Web Tokens
Lär dig vad en JWT (JSON Web Token) är, hur de tre delarna fungerar, var de används och viktiga säkerhetstips för att undvika vanliga tokenmisstag.
Lär dig vad en JWT (JSON Web Token) är, hur de tre delarna fungerar, var de används och viktiga säkerhetstips för att undvika vanliga tokenmisstag.
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>.
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:
Viktig nyans: “stateless” betyder inte “inga serverkontroller någonsin.” Många verkliga system validerar fortfarande tokens mot användarstatus, nyckelrotation eller återkallandemekanismer.
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.
Du ser ofta JWTs använda som access tokens i:
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…
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ändeskid: en nyckelidentifierare för att hjälpa verifieraren välja rätt nyckel vid rotationSäkerhetsnotering: lita inte blint på headern. Inför en tillåtlistning av algoritmer du faktiskt använder, och acceptera inte alg: "none".
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.
Signaturen skapas genom att signera header + payload med en nyckel:
Signaturen ger integritet: den låter servern verifiera att token inte ändrats och att den skapats av en betrodd signerare. Den ger inte konfidentialitet.
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.
Claims faller generellt i två kategorier: registered (standardiserade namn) och custom (dina apps fält).
iss (issuer): vem som skapade tokensub (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 accepterasiat (issued at): när token skapadesnbf (not before): token ska inte accepteras före denna tidInkludera bara vad den mottagande tjänsten verkligen behöver för att fatta ett auktorisationsbeslut.
Bra exempel:
user_id)Undvik “bekvämlighetsclaims” som duplicerar mycket profildata. De ökar tokenstorleken, blir snabbt inaktuella och ökar skadan om token läcker.
Eftersom payload är läsbar, lagra inte:
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.
Signering är inte kryptering.
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 ä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 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 tokens är typiskt kortlivade (minuter). Korta livstider begränsar skadan vid läckage.
OIDC lägger till autentisering (vem användaren är) ovanpå OAuth 2.0 och introducerar en ID token, som vanligtvis är en JWT.
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.
Ett typiskt flöde ser ut så här:
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.
Servern signerar token och returnerar den till klienten (webbapp, mobilapp eller annan tjänst).
För skyddade endpoints inkluderar klienten JWT i Authorization-headern:
Authorization: Bearer <JWT>
Innan förfrågan hanteras, kontrollerar API:t vanligen:
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).
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.
Val av lagring förändrar vad angripare kan stjäla och hur lätt de kan återanvända en token.
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:
HttpOnlySecure (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.
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.
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.
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.
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.
Giltiga signaturer räcker inte. Verifiera iss och aud, och validera tidsbaserade claims som exp och nbf.
Avkodning är inte verifiering. Verifiera alltid signaturen på servern och genomdriv behörigheter på serversidan.
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 ....
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.
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.
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.
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.
Verifiera med rätt nyckel och förväntad algoritm. Avvisa ogiltiga signaturer—inga undantag.
exp (expiration)Säkerställ att token inte har gått ut.
nbf (not before)Om det finns, säkerställ att token inte används för tidigt.
aud (audience)Bekräfta att token var menad för ditt API/tjänst.
iss (issuer)Bekräfta att token kom från förväntad utgivare.
Validera tokenformat, införa maxstorlek och avvisa oväntade claim-typer för att minska kantfallsbuggar.
HS256 (symmetrisk nyckel): en delad hemlighet signerar och verifierar.
RS256 / ES256 (asymmetriska nycklar): privat nyckel signerar; publik nyckel verifierar.
Tumregel: om mer än ett oberoende system behöver verifiera tokens (eller du inte litar fullt ut på varje verifierare), föredra RS256/ES256.
iss, aud, och ett användar-ID endast om policyn tillåter).Ä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.
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).
En JWT (JSON Web Token) är en kompakt, URL-säker sträng som bär claims (datafält) och som en server kan verifiera. Den skickas ofta i API-förfrågningar via:
Authorization: Bearer <token>Huvudidén: servern kan validera tokenens integritet (via dess signatur) utan att behöva en per-användare sessionspost för varje förfrågan.
Sessionbaserad autentisering lagrar vanligtvis tillstånd på servern (en sessionspost som nycklas med en cookie/session-id). Med JWT-baserad autentisering presenterar klienten en signerad token vid varje förfrågan och API:t validerar den.
JWT:er är populära för API:er och multi-service-arkitekturer eftersom verifiering kan ske lokalt, vilket minskar behovet av delad sessionlagring.
”Stateless” innebär inte att man aldrig gör serverkontroller — många system har fortfarande kontroller som svartlistor, användarstatuskontroller eller nyckelrotation.
En JWT består av tre Base64URL-kodade delar separerade med punkter:
header.payload.signatureHeader beskriver hur den signerades, payload innehåller claims (som sub, exp, aud) och signaturen låter servern upptäcka manipulering.
Nej. Standard-JWT:er är vanligtvis signerade, inte krypterade.
Om du behöver sekretess, överväg JWE (krypterade tokens) eller håll känslig data på serversidan och ha bara ett ID i JWT:n.
Signaturen låter servern verifiera att token inte ändrats och att den skapats av någon med signeringsnyckeln.
Den garanterar inte:
expBehandla token som en credential: om den läcker kan den ofta återanvändas tills den går ut.
alg talar om vilken algoritm som användes (t.ex. HS256 vs RS256). kid är en nyckelidentifierare som hjälper till att välja rätt verifieringsnyckel vid rotation.
Säkerhetsregler:
Börja med standardiserade registrerade claims och håll anpassade claims minimala.
Vanliga registrerade claims:
JWT är ett tokenformat; OAuth 2.0 och OpenID Connect är protokoll.
Typisk koppling:
För webbläsarappar är vanliga alternativ:
Minimera vad en token kan göra: använd minsta möjliga scopes/claims, håll access tokens kortlivade och undvik att bädda in känslig data.
Minst följande bör valideras:
exp (inte utgången)iss (förväntad utgivare)aud (avsett för din API)nbf (om det finns)Lägg också till praktiska skyddsåtgärder:
alg.alg: "none".kid orsaka osäker nyckeluppslagning.iss (issuer)sub (subject / användar-id)aud (audience / avsedd API)exp (expiration)iat (issued at)nbf (not before)Undvik att lägga hemligheter eller känsliga personuppgifter i payloaden, eftersom den är läsbar om token exponeras.
Viktigt: använd inte en ID token för att anropa ett API bara för att den liknar en access token.
Om du använder cookies, sätt:
HttpOnlySecure (endast HTTPS)SameSite=Lax eller SameSite=Strict (vissa cross-site-flöden kan behöva SameSite=None; Secure)Överväg även CSRF-token för ändringsoperationer.