Hvordan sikrer du et REST-API (autentisering, autorisasjon, transport)?

Question

IT Interview Practice · Accepted Answer

Å sikre et REST-API betyr å svare på tre spørsmål ved hver request: **hvem er du** (authentication), **hva har du lov til å gjøre** (authorization), og **er kanalen privat** (transport). Fordi REST er **stateless**, må credentials følge med hver request i stedet for å ligge i en server-sesjon.

## Transport: alltid HTTPS

Alt nedenfor forutsetter **TLS/HTTPS**. Uten det følger tokens og API-nøkler med i klartekst og kan snappes opp. Dette er ikke til forhandling — et bearer token over HTTP er et lekket token.

## Autentiseringsalternativer

**API-nøkler** — en statisk hemmelighet i en header. Enkelt; bra for server-til-server og for å identifisere en *applikasjon*, ikke en bruker. Svake alene (ingen utløp, ingen scope) med mindre de kombineres med mer.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — standarden for **delegert** tilgang ("la App X lese dataene mine uten passordet mitt"). Appen skaffer et **access token** via en flow (f.eks. Authorization Code) og sender det som et bearer token. Dette er hvordan "Sign in with Google" og tredjepartsintegrasjoner fungerer.

**JWT (JSON Web Token)** — et vanlig *format* for tokens: et signert, selvstendig token som bærer claims (user id, roller, utløp). Serveren verifiserer signaturen — ingen databaseoppslag nødvendig, som passer stateless REST.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Autorisasjon: scopes og roller

Autentisering beviser identitet; **autorisasjon** avgjør tilgang. Tokens bærer **scopes** (`orders:read`, `orders:write`) eller roller; serveren sjekker dem per endepunkt og returnerer `403 Forbidden` når de er utilstrekkelige (vs `401` for manglende/ugyldig auth).

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

## Andre nødvendigheter

```text
✓ Kortlevde access tokens + refresh tokens (begrens skadeomfang ved lekkasje)
✓ Rate limiting (429) for å dempe brute-force og misbruk
✓ Valider/saniter all input; stol aldri på klienten
✓ Prinsippet om minste privilegium på scopes
```

## Hvorfor det er viktig

Sikkerhet er der en liten feil blir et brudd, så intervjuere bruker dette til å se om du resonnerer om det strukturelt snarere enn å ramse opp buzzwords. Signalet de ser etter er at du **skiller de tre lagene** — transport (HTTPS, alltid), autentisering (bevise identitet, stateless, via bearer tokens/JWT/OAuth), og autorisasjon (scopes og minste privilegium) — og at du ikke blander dem sammen, f.eks. korrekt bruk av `401` for "ikke autentisert" kontra `403` for "autentisert, men ikke tillatt". Sterke svar viser bevissthet om de praktiske avveiingene: JWT-er er praktiske og stateless, men vanskelige å tilbakekalle før de utløper (derav korte levetider pluss refresh tokens), API-nøkler identifiserer apper, ikke brukere, og OAuth finnes nettopp for at brukere ikke skal gi passordet sitt til tredjeparter. Å knytte det til REST sin statelessness — credentials på hver request, ingen server-sesjon — viser at du forstår *hvorfor* API-sikkerhet ser ut som den gjør.

Transport: alltid HTTPS

Autentiseringsalternativer

Autorisasjon: scopes og roller

Andre nødvendigheter

Hvorfor det er viktig

Relaterte spørsmål