Hvordan fungerer et JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

Et **JSON Web Token (JWT)** er et kompakt, URL-sikkert, selvstændigt token, der bærer claims om en bruger. Serveren signerer det én gang; derefter kan den **verificere** tokenet ved hver request uden et databaseopslag — det er dét, der gør JWT-baseret auth *stateless*.

## Struktur: tre base64url-dele

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

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

- **Header** — signeringsalgoritmen, f.eks. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **claims'ene**: standardiserede som `sub` (subject/user id), `exp` (udløb), `iat` (issued-at), `iss` (issuer), plus eventuelle brugerdefinerede felter (`role`, `email`).
- **Signature** — beregnet over header og payload med en secret eller en privat nøgle.

> Payloaden er **kodet, ikke krypteret**. Enhver kan base64-dekode og læse den, så læg aldrig adgangskoder eller hemmeligheder i et JWT.

## Sådan fungerer signering og verifikation

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

- **HS256** (symmetrisk): den samme secret signerer og verificerer. Enkelt, men enhver verifikator skal holde secret'en.
- **RS256** (asymmetrisk): en **privat nøgle** signerer, en **offentlig nøgle** verificerer. Auth-serveren beholder den private nøgle; andre tjenester verificerer med den offentlige nøgle og kan aldrig udstede tokens.

Ved hver request genberegner serveren signaturen over den modtagne header+payload og sammenligner den. Hvis de matcher, og `exp` er i fremtiden, betros tokenet — ingen session-store nødvendig.

```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 manipuleret eller udløbet
  // claims.sub === "123"
} catch (e) {
  // afvis: ugyldig eller udløbet
}
```

## Den svære del: tilbagekaldelse (revocation)

Fordi verifikation er stateless, **kan du ikke** ugyldiggøre et token før det udløber ved bare at "slette" det på serversiden. Almindelige afbødninger:

- Hold access tokens **kortlivede** (5–15 min) og par dem med et længerelevende **refresh token**.
- Vedligehold en lille **denylist** over tilbagekaldte token-id'er (`jti`) til logout/kompromittering — dette genindfører lidt state.
- Rotér signeringsnøgler.

## Lagrings-trade-offs

| Lagring | Fordel | Ulempe |
|---|---|---|
| `httpOnly`-cookie | Ikke læsbar af JS (mere XSS-sikker) | Kræver CSRF-beskyttelse |
| `localStorage` | Enkelt, ingen CSRF | Eksponeret for XSS |

## Hvorfor det betyder noget

JWT'er driver stateless autentificering på tværs af API'er, microservices og SPA'er — en tjeneste kan betro en request alene ved at verificere en signatur, uden en delt session-store. Men netop den statelessness er den klassiske interviewfælde: tokens kan ikke let tilbagekaldes, payloaden er læsbar, og `alg`-forvirring eller et manglende udløbstjek er reelle sårbarheder. At vide præcis, hvad signaturen beskytter, og hvad den ikke gør, er afgørende for at bruge JWT'er sikkert.

Lagring	Fordel	Ulempe
`httpOnly`-cookie	Ikke læsbar af JS (mere XSS-sikker)	Kræver CSRF-beskyttelse
`localStorage`	Enkelt, ingen CSRF	Eksponeret for XSS

Struktur: tre base64url-dele

Sådan fungerer signering og verifikation

Den svære del: tilbagekaldelse (revocation)

Lagrings-trade-offs

Hvorfor det betyder noget

Relaterede spørgsmål