Kaip veikia JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

**JSON Web Token (JWT)** yra kompaktiškas, URL saugus, savarankiškas token'as, nešantis claim'us apie vartotoją. Serveris jį pasirašo vieną kartą; vėliau jis gali **verify** token'ą kiekviename request'e be duomenų bazės užklausos — būtent tai daro JWT pagrindu veikiantį auth *stateless*.

## Struktūra: trys base64url dalys

JWT yra `header.payload.signature`, trys base64url užkoduoti segmentai, sujungti taškais:

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

- **Header** — pasirašymo algoritmas, pvz. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **claim'ai**: standartiniai kaip `sub` (subjektas/vartotojo id), `exp` (galiojimo pabaiga), `iat` (išdavimo laikas), `iss` (išdavėjas), plius bet kokie pasirinktiniai laukai (`role`, `email`).
- **Signature** — apskaičiuotas ant header ir payload su secret arba privačiu raktu.

> Payload yra **užkoduotas, o ne užšifruotas**. Bet kas gali base64-decode ir perskaityti, todėl niekada nedėkite slaptažodžių ar paslapčių į JWT.

## Kaip veikia pasirašymas ir tikrinimas

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

- **HS256** (simetrinis): ta pati secret pasirašo ir tikrina. Paprasta, bet kiekvienas tikrintojas turi laikyti secret.
- **RS256** (asimetrinis): **privatus raktas** pasirašo, **viešas raktas** tikrina. Auth serveris laiko privatų raktą; kitos tarnybos tikrina viešu raktu ir niekada negali kaldinti token'ų.

Kiekviename request'e serveris perskaičiuoja signature ant gauto header+payload ir palygina. Jei sutampa ir `exp` yra ateityje, token'as patikimas — jokia session saugykla nereikalinga.

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

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

try {
  const claims = jwt.verify(token, SECRET); // meta klaidą, jei suklastota ar pasibaigė
  // claims.sub === "123"
} catch (e) {
  // atmesti: netinkamas arba pasibaigęs
}
```

## Sunkioji dalis: atšaukimas

Kadangi tikrinimas yra stateless, jūs **negalite** panaikinti token'o prieš jo galiojimo pabaigą tiesiog jį „ištrindami" serverio pusėje. Įprasti sprendimai:

- Laikykite access token'us **trumpalaikius** (5–15 min.) ir suporuokite su ilgesnio galiojimo **refresh token'u**.
- Palaikykite nedidelį atšauktų token'ų id (`jti`) **denylist** atsijungimui/kompromitavimui — tai vėl įneša truputį state.
- Rotuokite pasirašymo raktus.

## Saugojimo kompromisai

| Saugojimas | Privalumas | Trūkumas |
|---|---|---|
| `httpOnly` cookie | JS neįskaitomas (saugesnis nuo XSS) | Reikia CSRF apsaugos |
| `localStorage` | Paprasta, be CSRF | Atviras XSS |

## Kodėl tai svarbu

JWT maitina stateless autentifikaciją per API, mikroservisus ir SPA — tarnyba gali pasitikėti request'u vien patikrinusi parašą, be bendros session saugyklos. Bet tas pats statelesumas yra klasikiniai pašnekovo spąstai: token'ų negalima lengvai atšaukti, payload įskaitomas, o `alg` painiava ar praleistas galiojimo patikrinimas yra tikri pažeidžiamumai. Tiksliai žinoti, ką parašas apsaugo, o ko ne, yra būtina saugiai naudoti JWT.

Saugojimas	Privalumas	Trūkumas
`httpOnly` cookie	JS neįskaitomas (saugesnis nuo XSS)	Reikia CSRF apsaugos
`localStorage`	Paprasta, be CSRF	Atviras XSS

Struktūra: trys base64url dalys

Kaip veikia pasirašymas ir tikrinimas

Sunkioji dalis: atšaukimas

Saugojimo kompromisai

Kodėl tai svarbu

Susiję klausimai