Hogyan működik a JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

A **JSON Web Token (JWT)** egy kompakt, URL-biztos, önálló token, amely állításokat (claims) hordoz egy felhasználóról. A szerver egyszer aláírja; utána minden kérésnél **ellenőrizni** tudja a tokent adatbázis-lekérdezés nélkül — ez teszi a JWT-alapú hitelesítést *állapotmentessé (stateless)*.

## Szerkezet: három base64url rész

Egy JWT `header.payload.signature`, három base64url-kódolt szegmens pontokkal összefűzve:

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

- **Header** — az aláíró algoritmus, pl. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — a **claimek (állítások)**: standardok, mint `sub` (subject/user id), `exp` (lejárat), `iat` (kiállítás ideje), `iss` (kiállító), plusz bármilyen egyéni mező (`role`, `email`).
- **Signature** — a header és payload felett számolva egy secrettel vagy private key-vel.

> A payload **kódolt, nem titkosított**. Bárki base64-dekódolhatja és elolvashatja, ezért soha ne tegyél jelszavakat vagy titkokat egy JWT-be.

## Hogyan működik az aláírás és ellenőrzés

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

- **HS256** (szimmetrikus): ugyanaz a secret ír alá és ellenőriz. Egyszerű, de minden ellenőrzőnek birtokolnia kell a secretet.
- **RS256** (aszimmetrikus): egy **private key** ír alá, egy **public key** ellenőriz. A hitelesítő szerver tartja a private key-t; más szolgáltatások a public key-vel ellenőriznek, és soha nem tudnak tokent gyártani.

Minden kérésnél a szerver újraszámolja az aláírást a kapott header+payload felett, és összehasonlítja. Ha egyeznek és az `exp` a jövőben van, a token megbízható — nincs szükség session-tárolóra.

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

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

try {
  const claims = jwt.verify(token, SECRET); // hibát dob, ha meghamisították vagy lejárt
  // claims.sub === "123"
} catch (e) {
  // elutasítás: érvénytelen vagy lejárt
}
```

## A nehéz rész: visszavonás (revocation)

Mivel az ellenőrzés állapotmentes, **nem** tudsz érvényteleníteni egy tokent a lejárta előtt pusztán azzal, hogy szerveroldalon „törlöd”. Gyakori enyhítések:

- Tartsd az access tokeneket **rövid életűnek** (5–15 perc), és párosítsd egy hosszabb életű **refresh tokennel**.
- Tarts fenn egy kis **denylistet** a visszavont token-idekről (`jti`) a kijelentkezéshez/kompromittálódáshoz — ez visszahoz egy kis állapotot.
- Forgasd az aláíró kulcsokat.

## Tárolási kompromisszumok

| Tárolás | Előny | Hátrány |
|---|---|---|
| `httpOnly` cookie | JS nem olvashatja (XSS-biztosabb) | CSRF-védelmet igényel |
| `localStorage` | Egyszerű, nincs CSRF | Ki van téve XSS-nek |

## Miért fontos

A JWT-k állapotmentes hitelesítést hajtanak API-k, mikroszolgáltatások és SPA-k között — egy szolgáltatás pusztán egy aláírás ellenőrzésével megbízhat egy kérésben, közös session-tároló nélkül. De épp ez az állapotmentesség a klasszikus interjúcsapda: a tokeneket nem lehet könnyen visszavonni, a payload olvasható, és az `alg`-zavar vagy egy hiányzó lejárat-ellenőrzés valós sebezhetőségek. Pontosan tudni, mit véd az aláírás és mit nem, elengedhetetlen a JWT-k biztonságos használatához.

Tárolás	Előny	Hátrány
`httpOnly` cookie	JS nem olvashatja (XSS-biztosabb)	CSRF-védelmet igényel
`localStorage`	Egyszerű, nincs CSRF	Ki van téve XSS-nek

Szerkezet: három base64url rész

Hogyan működik az aláírás és ellenőrzés

A nehéz rész: visszavonás (revocation)

Tárolási kompromisszumok

Miért fontos

Kapcsolódó kérdések