# JWT exp och nbf: så kontrollerar du tiden i en token

*6 november 2026*

> Fälten exp och nbf i en JWT bestämmer när en token får användas. Så läser du tidsvärdena och kontrollerar dem mot klockan.

En JWT är en token med tre delar, skilda av punkter: header, payload och signatur. Payloaden innehåller påståenden, så kallade claims. Två av dem, exp och nbf, säger när token får användas. Fältet exp anger när token går ut. Fältet nbf anger tidigast när token får godtas. Båda är valfria, men en mottagare som kontrollerar tid ska läsa dem och jämföra dem med sin egen klocka.

## Vad exp och nbf betyder

RFC 7519, som definierar JWT, säger att exp är tidpunkten på eller efter vilken token inte längre får godtas. Kontrollen kräver att den aktuella tiden är före värdet i exp. Fältet nbf fungerar tvärtom: token får inte godtas före nbf, och den aktuella tiden ska vara lika med eller senare än värdet.

Det betyder att exp är en gräns som tar slut och nbf är en gräns som börjar gälla. En token kan alltså ha båda, bara den ena eller ingen av dem.

## Så räknas tiden

Tidsvärdena i exp och nbf kallas NumericDate i RFC 7519. Det är ett JSON-tal som anger antal sekunder från 1 januari 1970 klockan 00:00:00 UTC. Det är samma princip som Unixtid, som beskrivs på svenska Wikipedia som antal sekunder som förflutit sedan midnatt 1 januari 1970 i UTC. RFC 7519 specificerar att skottsekunder inte räknas med.

Det innebär att värdet inte har någon tidszon. Ett exp-värde är samma tidpunkt för alla, oavsett om servern står i Stockholm eller i Tokyo. Tidszonen uppstår först när man visar värdet för en människa.

Ta ett exempel. Värdet 1793966400 motsvarar 6 november 2026 klockan 12:00 UTC, eller 13:00 i Sverige. Om exp har det värdet är token ogiltig från och med klockan 12:00 UTC. Om nbf är 1793962800 är token giltig tidigast klockan 11:00 UTC. Mellan 11:00 och 12:00 UTC gäller den alltså.

## Kontrollera tiden i praktiken

En enkel kontroll ser ut så här:

1. Hämta nu-tiden i sekunder sedan epoken, till exempel med Date.now() dividerat med 1000 och avrundat nedåt.
2. Om exp finns och nu är lika med eller större än exp, avvisa token.
3. Om nbf finns och nu är mindre än nbf, avvisa token.

RFC 7519 säger att mottagaren får tillåta en liten marginal för klockskillnader mellan system, som oftast inte bör vara mer än några minuter. Marginalen gäller både exp och nbf, och den bör vara tydligt dokumenterad i koden. En stor marginal gör att utgångna token godtas längre än avsett.

Glöm inte att läsa payloaden är inte samma sak som att kontrollera token. RFC 7519 kräver att signaturen valideras innan påståendena används. En token vars payload ser riktig ut kan vara förfalskad. Först när signaturen är godkänd är det meningsfullt att läsa exp och nbf.

## Vanliga fel

Det vanligaste felet är att blanda ihop sekunder och millisekunder. JavaScripts Date.now() ger millisekunder, medan exp och nbf är i sekunder. Ett exp-värde jämfört med millisekunder ser ut att vara långt in i framtiden, och token verkar aldrig gå ut.

Det andra felet är att tolka datum som text. Fälten är tal, inte datumsträngar. Om payloaden innehåller ett ISO-datum i stället för ett tal, är den inte en giltig NumericDate enligt RFC 7519.

Det tredje felet är att glömma nbf. Många implementationer kontrollerar bara exp. Om servern därför inte läser nbf kan en token som ska börja gälla senare användas redan innan dess.

Det fjärde felet är att räkna från fel startpunkt. Epoken är 1 januari 1970 i UTC. Om man använder lokal tid i en beräkning blir värdet fel med en eller två timmar.

## Sammanfattning av kontrollen

exp: token gäller tills nu är mindre än exp. nbf: token gäller från och med nbf. Båda är tal i sekunder sedan 1 januari 1970 UTC. Marginalen för klockskillnader ska vara liten och dokumenterad. Signaturen ska vara godkänd innan du litar på något av fälten.