JSON Web Token (JWT) hufanya kazi vipi?

Question

IT Interview Practice · Accepted Answer

**JSON Web Token (JWT)** ni token fupi, salama kwa URL, inayojitosheleza, inayobeba claims kuhusu mtumiaji. Server huitia saini mara moja; baadaye huweza **kuithibitisha** token kwa kila request bila kutafuta database — hilo ndilo linalofanya uthibitishaji unaotegemea JWT kuwa *stateless*.

## Muundo: sehemu tatu za base64url

JWT ni `header.payload.signature`, sehemu tatu zilizosimbwa kwa base64url zikiunganishwa kwa nukta:

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

- **Header** — algorithm ya kutia saini, k.m. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **claims**: za kawaida kama `sub` (subject/user id), `exp` (kuisha), `iat` (iliyotolewa), `iss` (mtoaji), pamoja na fields zozote za desturi (`role`, `email`).
- **Signature** — inayohesabiwa juu ya header na payload kwa secret au private key.

> Payload ime **simbwa (encoded), si kufichwa (encrypted)**. Yeyote anaweza kui-base64-decode na kuisoma, hivyo usiweke kamwe passwords au siri ndani ya JWT.

## Jinsi kutia saini na uthibitishaji vinavyofanya kazi

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

- **HS256** (symmetric): secret ile ile hutia saini na kuthibitisha. Rahisi, lakini kila mthibitishaji lazima ashikilie secret.
- **RS256** (asymmetric): **private key** hutia saini, **public key** huthibitisha. Server ya uthibitishaji hushikilia private key; services nyingine huthibitisha kwa public key na haziwezi kamwe kutengeneza tokens.

Kwa kila request server huhesabu upya signature juu ya header+payload iliyopokelewa na kuilinganisha. Ikilingana na `exp` iko wakati ujao, token huaminiwa — hakuna session store inayohitajika.

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

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

try {
  const claims = jwt.verify(token, SECRET); // hutupa iwapo imechezewa au imeisha
  // claims.sub === "123"
} catch (e) {
  // kataa: si halali au imeisha
}
```

## Sehemu ngumu: kufuta (revocation)

Kwa sababu uthibitishaji ni stateless, **huwezi** kubatilisha token kabla haijaisha kwa kuifuta tu upande wa server. Njia za kawaida za kupunguza:

- Weka access tokens **za muda mfupi** (dakika 5–15) na uziunganishe na **refresh token** yenye muda mrefu zaidi.
- Dumisha **denylist** ndogo ya ids za tokens zilizofutwa (`jti`) kwa kutoka/kuathiriwa — hii hurejesha state kidogo.
- Zungusha keys za kutia saini.

## Mabadilishano ya uhifadhi

| Uhifadhi | Faida | Hasara |
|---|---|---|
| Cookie ya `httpOnly` | Haisomwi na JS (salama zaidi dhidi ya XSS) | Huhitaji ulinzi wa CSRF |
| `localStorage` | Rahisi, hakuna CSRF | Imeachwa wazi kwa XSS |

## Kwa nini ni muhimu

JWTs huwezesha uthibitishaji wa stateless katika APIs, microservices, na SPAs — service huweza kuamini request kwa kuthibitisha signature pekee, bila session store ya pamoja. Lakini statelessness hiyo hiyo ndiyo mtego wa kawaida wa mahojiano: tokens haziwezi kufutwa kwa urahisi, payload husomeka, na mkanganyiko wa `alg` au ukaguzi wa kuisha uliokosekana ni udhaifu halisi. Kujua hasa signature inalinda nini, na isicholilinda, ni muhimu kwa kutumia JWTs kwa usalama.

Uhifadhi	Faida	Hasara
Cookie ya `httpOnly`	Haisomwi na JS (salama zaidi dhidi ya XSS)	Huhitaji ulinzi wa CSRF
`localStorage`	Rahisi, hakuna CSRF	Imeachwa wazi kwa XSS

Muundo: sehemu tatu za base64url

Jinsi kutia saini na uthibitishaji vinavyofanya kazi

Sehemu ngumu: kufuta (revocation)

Mabadilishano ya uhifadhi

Kwa nini ni muhimu

Maswali yanayohusiana