Cum funcționează un JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

Un **JSON Web Token (JWT)** este un token compact, sigur pentru URL, autonom, care poartă declarații (claims) despre un utilizator. Serverul îl semnează o singură dată; după aceea poate **verifica** token-ul la fiecare cerere fără o interogare în baza de date — asta face autentificarea bazată pe JWT *stateless* (fără stare).

## Structură: trei părți base64url

Un JWT este `header.payload.signature`, trei segmente codate base64url unite prin puncte:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — algoritmul de semnare, ex. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **declarațiile** (claims): cele standard precum `sub` (subiect/id utilizator), `exp` (expirare), `iat` (emis la), `iss` (emitent), plus orice câmpuri personalizate (`role`, `email`).
- **Signature** — calculată peste header și payload cu un secret sau o cheie privată.

> Payload-ul este **codat, nu criptat**. Oricine îl poate decoda din base64 și citi, așa că nu pune niciodată parole sau secrete într-un JWT.

## Cum funcționează semnarea și verificarea

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (simetric): același secret semnează și verifică. Simplu, dar fiecare verificator trebuie să dețină secretul.
- **RS256** (asimetric): o **cheie privată** semnează, o **cheie publică** verifică. Serverul de autentificare păstrează cheia privată; alte servicii verifică cu cheia publică și nu pot niciodată să emită token-uri.

La fiecare cerere, serverul recalculează semnătura peste header+payload primite și o compară. Dacă se potrivesc și `exp` este în viitor, token-ul este de încredere — nu e nevoie de un depozit de sesiuni.

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // aruncă eroare dacă e alterat sau expirat
  // claims.sub === "123"
} catch (e) {
  // respinge: invalid sau expirat
}
```

## Partea grea: revocarea

Deoarece verificarea este stateless, **nu poți** invalida un token înainte de expirare doar „ștergându-l" pe partea de server. Măsuri comune de atenuare:

- Ține token-urile de acces **cu viață scurtă** (5–15 min) și împerechează-le cu un **refresh token** cu viață mai lungă.
- Menține o mică **denylist** de id-uri de token-uri revocate (`jti`) pentru delogare/compromitere — asta reintroduce puțină stare.
- Rotește cheile de semnare.

## Compromisuri de stocare

| Stocare | Avantaj | Dezavantaj |
|---|---|---|
| Cookie `httpOnly` | Nu poate fi citit de JS (mai sigur față de XSS) | Necesită protecție CSRF |
| `localStorage` | Simplu, fără CSRF | Expus la XSS |

## De ce contează

JWT-urile alimentează autentificarea stateless în API-uri, microservicii și SPA-uri — un serviciu poate avea încredere într-o cerere doar verificând o semnătură, fără un depozit de sesiuni partajat. Dar aceeași lipsă de stare este clasica capcană de interviu: token-urile nu pot fi revocate ușor, payload-ul este lizibil, iar confuzia `alg` sau lipsa verificării expirării sunt vulnerabilități reale. A ști exact ce protejează semnătura și ce nu este esențial pentru a folosi JWT-urile în siguranță.

Stocare	Avantaj	Dezavantaj
Cookie `httpOnly`	Nu poate fi citit de JS (mai sigur față de XSS)	Necesită protecție CSRF
`localStorage`	Simplu, fără CSRF	Expus la XSS

Structură: trei părți base64url

Cum funcționează semnarea și verificarea

Partea grea: revocarea

Compromisuri de stocare

De ce contează

Întrebări conexe