Hvordan fungerer et JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

Et **JSON Web Token (JWT)** er et kompakt, URL-sikkert, selvstendig token som bærer claims om en bruker. Serveren signerer det én gang; deretter kan den **verify** tokenet ved hver request uten databaseoppslag — det er det som gjør JWT-basert auth *stateless*.

## Struktur: tre base64url-deler

Et JWT er `header.payload.signature`, tre base64url-kodede segmenter forbundet med punktum:

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

- **Header** — signeringsalgoritmen, f.eks. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **claims**-ene: standardvarianter som `sub` (subject/bruker-id), `exp` (utløp), `iat` (issued-at), `iss` (issuer), pluss eventuelle egendefinerte felt (`role`, `email`).
- **Signature** — beregnet over header og payload med en secret eller privat nøkkel.

> Payload-en er **kodet, ikke kryptert**. Hvem som helst kan base64-dekode og lese den, så legg aldri passord eller hemmeligheter i et JWT.

## Hvordan signering og verifisering fungerer

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

- **HS256** (symmetrisk): den samme secret-en signerer og verifiserer. Enkelt, men hver verifiserer må ha secret-en.
- **RS256** (asymmetrisk): en **privat nøkkel** signerer, en **offentlig nøkkel** verifiserer. Auth-serveren beholder den private nøkkelen; andre tjenester verifiserer med den offentlige nøkkelen og kan aldri lage tokens.

Ved hver request beregner serveren signaturen på nytt over den mottatte header+payload og sammenligner dem. Hvis de stemmer og `exp` er i fremtiden, stoles det på tokenet — ingen session store trengs.

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

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

try {
  const claims = jwt.verify(token, SECRET); // kaster hvis tuklet med eller utløpt
  // claims.sub === "123"
} catch (e) {
  // avvis: ugyldig eller utløpt
}
```

## Den vanskelige delen: tilbakekalling

Fordi verifisering er stateless, kan du **ikke** ugyldiggjøre et token før det utløper bare ved å "slette" det server-side. Vanlige tiltak:

- Hold access tokens **kortlevde** (5–15 min) og par dem med et lengrelevd **refresh token**.
- Vedlikehold en liten **denylist** over tilbakekalte token- id-er (`jti`) for logout/kompromittering — dette gjeninnfører litt state.
- Roter signeringsnøklene.

## Lagrings-avveiinger

| Lagring | Fordel | Ulempe |
|---|---|---|
| `httpOnly`-cookie | Ikke lesbar av JS (tryggere mot XSS) | Trenger CSRF-beskyttelse |
| `localStorage` | Enkelt, ingen CSRF | Eksponert for XSS |

## Hvorfor det er viktig

JWT-er driver stateless autentisering på tvers av API-er, mikrotjenester og SPA-er — en tjeneste kan stole på en request ved kun å verifisere en signatur, uten en delt session store. Men nettopp denne statelessness-en er den klassiske intervjufellen: tokens kan ikke enkelt tilbakekalles, payload-en er lesbar, og `alg`-forvirring eller en manglende utløpssjekk er reelle sårbarheter. Å vite nøyaktig hva signaturen beskytter, og hva den ikke gjør, er avgjørende for å bruke JWT-er trygt.

Lagring	Fordel	Ulempe
`httpOnly`-cookie	Ikke lesbar av JS (tryggere mot XSS)	Trenger CSRF-beskyttelse
`localStorage`	Enkelt, ingen CSRF	Eksponert for XSS

Struktur: tre base64url-deler

Hvordan signering og verifisering fungerer

Den vanskelige delen: tilbakekalling

Lagrings-avveiinger

Hvorfor det er viktig

Relaterte spørsmål