Hur säkrar du ett REST-API (autentisering, auktorisering, transport)?

Question

IT Interview Practice · Accepted Answer

Att säkra ett REST-API betyder att besvara tre frågor vid varje request: **vem är du** (authentication), **vad får du göra** (authorization), och **är kanalen privat** (transport). Eftersom REST är **stateless** måste credentials färdas med varje request snarare än att bo i en server-session.

## Transport: alltid HTTPS

Allt nedan förutsätter **TLS/HTTPS**. Utan det färdas tokens och API keys i klartext och kan avlyssnas. Detta är icke förhandlingsbart — en bearer token över HTTP är en läckt token.

## Autentiseringsalternativ

**API keys** — en statisk hemlighet i en header. Enkelt; bra för server-till-server och för att identifiera en *applikation*, inte en user. Svaga på egen hand (ingen förfallotid, ingen scope) om de inte paras med mer.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — standarden för **delegerad** åtkomst ("låt App X läsa min data utan mitt lösenord"). Appen erhåller en **access token** via ett flow (t.ex. Authorization Code) och skickar den som en bearer token. Det är så "Sign in with Google" och tredjepartsintegrationer fungerar.

**JWT (JSON Web Token)** — ett vanligt *format* för tokens: en signerad, självständig token som bär claims (user id, roles, förfallotid). Servern verifierar signaturen — ingen databasuppslagning behövs, vilket passar stateless REST.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Auktorisering: scopes och roles

Authentication bevisar identitet; **authorization** avgör åtkomst. Tokens bär **scopes** (`orders:read`, `orders:write`) eller roles; servern kontrollerar dem per endpoint och returnerar `403 Forbidden` när de är otillräckliga (kontra `401` för saknad/ogiltig auth).

```text
No/invalid token         → 401 Unauthorized
Valid token, no scope    → 403 Forbidden
```

## Andra väsentligheter

```text
✓ Kortlivade access tokens + refresh tokens (begränsa skadeområdet om de läcker)
✓ Rate limiting (429) för att trubba av brute-force och missbruk
✓ Validera/sanera all input; lita aldrig på client:en
✓ Principen om least privilege på scopes
```

## Varför det är viktigt

Säkerhet är där ett litet misstag blir ett intrång, så intervjuare använder detta för att se om du resonerar om det strukturellt snarare än att rabbla buzzwords. Signalen de letar efter är att du **separerar de tre lagren** — transport (HTTPS, alltid), authentication (att bevisa identitet, statelessly, via bearer tokens/JWT/OAuth), och authorization (scopes och least privilege) — och att du inte blandar ihop dem, t.ex. korrekt använder `401` för "inte autentiserad" kontra `403` för "autentiserad men inte tillåten." Starka svar visar medvetenhet om de praktiska avvägningarna: JWT:er är bekväma och stateless men svåra att återkalla innan de förfaller (därav korta livslängder plus refresh tokens), API keys identifierar appar inte users, och OAuth existerar specifikt så att users inte lämnar sitt lösenord till tredje part. Att knyta det till REST:s statelessness — credentials vid varje request, ingen server-session — visar att du förstår *varför* API-säkerhet ser ut som den gör.

Transport: alltid HTTPS

Autentiseringsalternativ

Auktorisering: scopes och roles

Andra väsentligheter

Varför det är viktigt

Relaterade frågor