Timestampuri Unix pentru expirarea JWT-urilor și a tokenurilor — cum funcționează

Dacă ai decodat vreodată un JWT și ai văzut ceva de genul "exp": 1744070400, ai întâlnit timestampurile Unix într-una dintre cele mai comune utilizări practice. Sistemul de expirare al JSON Web Tokens este construit integral pe timpul Unix — iar odată ce înțelegi cum funcționează, depanarea problemelor cu tokenuri devine mult mai simplă.

Convertorul de timestampuri Unix transformă instant orice număr de timestamp brut într-o dată lizibilă. Articolul acesta explică modul în care claim-urile JWT folosesc timestampuri Unix, cum calculezi momentele de expirare și unde apar, de obicei, problemele.

Ce înseamnă de fapt exp și iat

Un payload JWT decodat arată cam așa:

{
  "sub": "user_12345",
  "iat": 1743984000,
  "exp": 1744070400,
  "role": "admin"
}

Atât iat (issued at), cât și exp (expiry) sunt timestampuri Unix — numărul de secunde de la 1 ianuarie 1970, 00:00:00 UTC. Nu au nicio legătură cu fusul orar local al serverului; sunt întotdeauna bazate pe UTC.

iat: 1743984000 înseamnă că tokenul a fost emis în acea secundă specifică din istorie. exp: 1744070400 înseamnă că tokenul devine invalid în acea secundă. Diferența dintre ele — 86.400 de secunde — este durata de viață autorizată a tokenului. În cazul acesta, exact 24 de ore.

Ca să verifici ce dată reprezintă aceste timestampuri, lipește oricare dintre numere în Convertorul de timestampuri Unix. 1743984000 se rezolvă la 7 aprilie 2026 00:00:00 UTC. 1744070400 se rezolvă la 8 aprilie 2026 00:00:00 UTC.

Cum se calculează durata de viață a unui token

Logica e simplă. Când un server emite un token, el:

1. Obține timestampul Unix curent (să-i zicem now) 2. Adaugă durata dorită în secunde 3. Setează suma drept claim-ul exp

Pentru un token de 1 oră: exp = now + 3600 Pentru un token de 24 de ore: exp = now + 86400 Pentru un token de 7 zile: exp = now + 604800 Pentru un token de 30 de zile: exp = now + 2592000

Când un client prezintă tokenul, serverul verifică dacă timestampul curent este mai mic decât exp. Dacă current_time > exp, tokenul este respins ca expirat.

Matematica este pur aritmetică pe întregi — fără conversii de fus orar, fără logică de calendar, fără cazuri-limită legate de lungimea lunilor. Acesta e unul dintre motivele pentru care timestampurile Unix sunt potrivite aici.

Durate de viață uzuale ale tokenurilor, în funcție de caz

Tokenurile de resetare a parolei și cele de verificare a emailului ar trebui să fie scurte — sunt de unică folosință și sensibile. Refresh tokenurile pot fi mai lungi pentru că sunt stocate în siguranță și pot fi revocate pe server.

Depanarea problemelor de expirare

Când un token este respins neașteptat, primul pas este să-l decodezi și să verifici câmpul exp. Majoritatea bibliotecilor JWT au o funcție de decodare care nu verifică semnătura — utilă pentru inspecție atunci când vrei doar să citești claim-urile.

După ce ai valoarea exp, lipește-o în Convertorul de timestampuri Unix ca să obții momentul de expirare într-un format lizibil. Compară-l cu timpul curent. Dacă tokenul a expirat acum trei ore, știi că problema este un token vechi. Dacă expirarea este în viitor și tokenul tot e respins, problema este altceva — semnătură nepotrivită, claim de audiență greșit sau o problemă de „clock skew”.

Clock skew este o problemă comună în sistemele distribuite. Dacă serverul care emite tokenul și serverul care îl validează au ceasuri diferite cu mai mult de câteva secunde, tokenurile pot fi respinse ca expirate când n-ar trebui sau acceptate când ar fi trebuit să expire. Din acest motiv, majoritatea bibliotecilor JWT permit o toleranță mică pentru clock skew — de obicei 30 de secunde până la 5 minute.

Claim-ul iat ajută aici. Dacă iat este în viitor din perspectiva serverului care validează, ceasul serverului emitent este înainte. Dacă exp - iat nu se potrivește cu durata de viață așteptată, ceva a mers prost la emitere.

Secunde vs milisecunde: un bug frecvent în JWT

Timestampurile Unix sunt în secunde. Date.now() din JavaScript întoarce milisecunde. Nepotrivirea asta produce buguri care pot fi greu de observat.

Dacă în Node.js faci asta:

const exp = Date.now() + 3600; // Greșit: Date.now() este în milisecunde

Ai setat o expirare de aproximativ 1 milisecundă în viitor (milisecunde curente + 3.600 milisecunde = practic acum). Tokenul va fi respins imediat.

Varianta corectă:

const exp = Math.floor(Date.now() / 1000) + 3600; // Corect: convertește în secunde mai întâi

Un număr cu 13 cifre în câmpul exp dintr-un JWT este un indiciu clar că s-au folosit milisecunde din greșeală. Timestampurile Unix standard au 10 cifre în 2026. Dacă vezi exp: 1744070400000, acel timestamp se rezolvă la anul 57.000 și ceva — un semn evident că milisecundele au ajuns într-un câmp de secunde.

Claim-ul nbf: Not Before

JWT suportă și claim-ul nbf (not before), tot un timestamp Unix. El specifică cel mai devreme moment la care tokenul este valid. Dacă current_time < nbf, tokenul este respins chiar dacă încă nu a expirat.

Este util pentru tokenuri care ar trebui să devină valabile în viitor — un drept de acces programat, un link de descărcare temporizat sau un token emis înaintea unui eveniment planificat. Combinația dintre nbf și exp definește o fereastră exactă de valabilitate.

Exemplu: `json { "nbf": 1744070400, "exp": 1744156800 } `

Acest token devine valid pe 8 aprilie 2026 00:00:00 UTC și expiră pe 9 aprilie 2026 00:00:00 UTC — o fereastră de 24 de ore care începe în viitor.

Revocarea tokenurilor înainte de expirare

O limitare a designului JWT stateless este că nu poți revoca un token înainte de momentul exp fără să menții stare pe server. Dacă un utilizator se deloghează sau un token este compromis, tokenul rămâne tehnic valid până expiră — cu excepția cazului în care implementezi o listă de blocare (blocklist).

Abordări comune:

• Tokenuri de acces cu durată scurtă + refresh tokenuri: Ține tokenurile de acces scurte (15 minute) ca să expire rapid. Revocă refresh tokenurile la logout. Tokenul de acces va expira curând de la sine.
• Blocklist de tokenuri: Stochează pe server ID-urile tokenurilor revocate (de obicei claim-ul jti) până trece exp. Mai mult overhead, dar permite revocare imediată.
• Rotirea tokenurilor: Emite un token de acces nou la fiecare refresh și invalidează-l pe cel vechi.

Timestampul Unix din exp este limita exterioară a valabilității. Logica aplicației tale determină dacă un token aflat în acea fereastră ar trebui, de fapt, onorat.

Citirea expirării în practică

Dacă depanezi un API și vrei să verifici rapid dacă un token este expirat, nu ai nevoie de o bibliotecă JWT completă. Decodează payload-ul (segmentul din mijloc al JWT-ului) din base64, parsează JSON-ul și compară câmpul exp cu timestampul Unix curent.

În consola browserului: `javascript const payload = JSON.parse(atob(token.split('.')[1])); console.log('Expires:', new Date(payload.exp * 1000).toISOString()); console.log('Expired:', Date.now() / 1000 > payload.exp); `

Sau pur și simplu lipește valoarea exp în Convertorul de timestampuri Unix ca să obții data într-un format lizibil fără să scrii cod. De cele mai multe ori, asta e cea mai rapidă cale de a răspunde la întrebarea „a expirat tokenul?” atunci când depanezi în producție.