Si funksionon një JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

Një **JSON Web Token (JWT)** është një token kompakt, i sigurt për URL, i vetëpërmbajtur, që bart pohime (claims) rreth një përdoruesi. Serveri e nënshkruan një herë; më pas mund ta **verifikojë** token-in në çdo kërkesë pa një kërkim në bazën e të dhënave — kjo është ajo që e bën autentikimin e bazuar në JWT *pa gjendje* (stateless).

## Struktura: tri pjesë base64url

Një JWT është `header.payload.signature`, tri segmente të koduara në base64url të bashkuara me pika:

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

- **Header** — algoritmi i nënshkrimit, p.sh. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **pohimet** (claims): standarde si `sub` (subjekti/id-ja e përdoruesit), `exp` (skadimi), `iat` (lëshuar në), `iss` (lëshuesi), plus çdo fushë e personalizuar (`role`, `email`).
- **Signature** — llogaritur mbi header-in dhe payload-in me një sekret ose çelës privat.

> Payload-i është **i koduar, jo i enkriptuar**. Kushdo mund ta dekodojë nga base64 dhe ta lexojë, kështu që kurrë mos vendos fjalëkalime apo sekrete në një JWT.

## Si funksionojnë nënshkrimi dhe verifikimi

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

- **HS256** (simetrik): i njëjti sekret nënshkruan dhe verifikon. I thjeshtë, por çdo verifikues duhet ta mbajë sekretin.
- **RS256** (asimetrik): një **çelës privat** nënshkruan, një **çelës publik** verifikon. Serveri i autentikimit e mban çelësin privat; shërbimet e tjera verifikojnë me çelësin publik dhe kurrë nuk mund të prodhojnë token-a.

Në çdo kërkesë serveri e rillogarit nënshkrimin mbi header+payload-in e marrë dhe e krahason. Nëse përputhen dhe `exp` është në të ardhmen, token-i besohet — nuk nevojitet asnjë ruajtëse sesioni.

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

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

try {
  const claims = jwt.verify(token, SECRET); // hedh gabim nëse është ndryshuar ose skaduar
  // claims.sub === "123"
} catch (e) {
  // refuzo: i pavlefshëm ose i skaduar
}
```

## Pjesa e vështirë: revokimi

Ngaqë verifikimi është pa gjendje, ju **nuk mund** ta pavlefshmëroni një token para se të skadojë thjesht duke e "fshirë" në anën e serverit. Zbutje të zakonshme:

- Mbaji token-at e aksesit **jetëshkurtër** (5–15 min) dhe çiftoji me një **refresh token** me jetë më të gjatë.
- Mbaj një **listë ndalimi** (denylist) të vogël me id-të e token-ave të revokuar (`jti`) për çkyçje/kompromentim — kjo rikthen pak gjendje.
- Rrotullo çelësat e nënshkrimit.

## Kompromiset e ruajtjes

| Ruajtja | E mira | E keqja |
|---|---|---|
| Cookie `httpOnly` | Nuk lexohet nga JS (më i sigurt ndaj XSS) | Ka nevojë për mbrojtje CSRF |
| `localStorage` | I thjeshtë, pa CSRF | I ekspozuar ndaj XSS |

## Pse ka rëndësi

JWT-të fuqizojnë autentikimin pa gjendje nëpër API, mikroshërbime dhe SPA — një shërbim mund t'i besojë një kërkese duke verifikuar vetëm një nënshkrim, pa një ruajtëse sesioni të përbashkët. Por po kjo mungesë gjendjeje është kurthi klasik i intervistës: token-at nuk mund të revokohen lehtë, payload-i lexohet, dhe ngatërresa e `alg` ose mungesa e kontrollit të skadimit janë dobësi të vërteta. Të dish saktësisht se çfarë mbron nënshkrimi, dhe çfarë jo, është thelbësore për të përdorur JWT-të në mënyrë të sigurt.

Ruajtja	E mira	E keqja
Cookie `httpOnly`	Nuk lexohet nga JS (më i sigurt ndaj XSS)	Ka nevojë për mbrojtje CSRF
`localStorage`	I thjeshtë, pa CSRF	I ekspozuar ndaj XSS

Struktura: tri pjesë base64url

Si funksionojnë nënshkrimi dhe verifikimi

Pjesa e vështirë: revokimi

Kompromiset e ruajtjes

Pse ka rëndësi

Pyetje të ngjashme