Hur fungerar en JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

En **JSON Web Token (JWT)** är en kompakt, URL-säker, självständig token som bär anspråk (claims) om en användare. Servern signerar den en gång; därefter kan den **verifiera** token vid varje request utan en databasuppslagning — det är det som gör JWT-baserad autentisering *stateless*.

## Struktur: tre base64url-delar

En JWT är `header.payload.signature`, tre base64url-kodade segment sammanfogade med punkter:

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

- **Header** — signeringsalgoritmen, t.ex. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **claims**: standardiserade som `sub` (subject/user id), `exp` (utgång), `iat` (utfärdad-vid), `iss` (utfärdare), plus valfria egna fält (`role`, `email`).
- **Signature** — beräknad över header och payload med en secret eller privat nyckel.

> Payload är **kodad, inte krypterad**. Vem som helst kan base64-avkoda och läsa den, så lägg aldrig lösenord eller hemligheter i en JWT.

## Hur signering och verifiering fungerar

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

- **HS256** (symmetrisk): samma secret signerar och verifierar. Enkelt, men varje verifierare måste inneha secret.
- **RS256** (asymmetrisk): en **privat nyckel** signerar, en **publik nyckel** verifierar. Autentiseringsservern behåller den privata nyckeln; andra tjänster verifierar med den publika nyckeln och kan aldrig skapa tokens.

Vid varje request räknar servern om signaturen över den mottagna headern+payloaden och jämför den. Om de matchar och `exp` ligger i framtiden litas token på — ingen session-lagring behövs.

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

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

try {
  const claims = jwt.verify(token, SECRET); // kastar om manipulerad eller utgången
  // claims.sub === "123"
} catch (e) {
  // avvisa: ogiltig eller utgången
}
```

## Det svåra: återkallelse (revocation)

Eftersom verifieringen är stateless kan du **inte** ogiltigförklara en token innan den går ut bara genom att "radera" den på serversidan. Vanliga motåtgärder:

- Håll access-tokens **kortlivade** (5–15 min) och para dem med en längre livad **refresh token**.
- Underhåll en liten **denylist** över återkallade token-id:n (`jti`) för utloggning/kompromettering — detta återinför lite state.
- Rotera signeringsnycklar.

## Avvägningar för lagring

| Lagring | Fördel | Nackdel |
|---|---|---|
| `httpOnly`-cookie | Inte läsbar av JS (XSS-säkrare) | Behöver CSRF-skydd |
| `localStorage` | Enkelt, ingen CSRF | Exponerad för XSS |

## Varför det är viktigt

JWT:er driver stateless autentisering över API:er, microservices och SPA:er — en tjänst kan lita på en request enbart genom att verifiera en signatur, utan en delad session-lagring. Men samma statelessness är den klassiska intervjufällan: tokens kan inte enkelt återkallas, payloaden är läsbar, och `alg`-förvirring eller en saknad utgångskontroll är verkliga sårbarheter. Att veta exakt vad signaturen skyddar, och vad den inte gör, är avgörande för att använda JWT:er säkert.

Lagring	Fördel	Nackdel
`httpOnly`-cookie	Inte läsbar av JS (XSS-säkrare)	Behöver CSRF-skydd
`localStorage`	Enkelt, ingen CSRF	Exponerad för XSS

Struktur: tre base64url-delar

Hur signering och verifiering fungerar

Det svåra: återkallelse (revocation)

Avvägningar för lagring

Varför det är viktigt

Relaterade frågor