Kako zavarujete REST API (avtentikacija, avtorizacija, transport)?

Question

IT Interview Practice · Accepted Answer

Zavarovanje REST API-ja pomeni odgovoriti na tri vprašanja ob vsaki zahtevi: **kdo si** (avtentikacija), **kaj smeš početi** (avtorizacija) in **ali je kanal zaseben** (transport). Ker je REST **stateless**, morajo poverilnice potovati z vsako zahtevo, ne pa živeti v seji strežnika.

## Transport: vedno HTTPS

Vse spodaj predpostavlja **TLS/HTTPS**. Brez njega tokeni in API ključi potujejo v čistem besedilu in jih je mogoče prisluškovati. To je nepogajljivo — bearer token prek HTTP je razkrit token.

## Možnosti avtentikacije

**API keys** — statična skrivnost v glavi. Preprosto; dobro za server-to-server in identifikacijo *aplikacije*, ne uporabnika. Sami po sebi šibki (brez poteka, brez obsega), razen če jih sparimo z več.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — standard za **delegiran** dostop ("naj App X bere moje podatke brez mojega gesla"). Aplikacija pridobi **access token** prek toka (npr. Authorization Code) in ga pošlje kot bearer token. Tako delujeta "Sign in with Google" in integracije tretjih oseb.

**JWT (JSON Web Token)** — pogosta *oblika* tokenov: podpisan, samozadosten token, ki nosi trditve (claims: user id, vloge, potek). Strežnik preveri podpis — brez poizvedbe v bazo, kar ustreza stateless REST-u.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Avtorizacija: obsegi (scopes) in vloge

Avtentikacija dokazuje identiteto; **avtorizacija** odloča o dostopu. Tokeni nosijo **obsege** (`orders:read`, `orders:write`) ali vloge; strežnik jih preveri na vsakem endpointu in vrne `403 Forbidden`, kadar so nezadostni (proti `401` za manjkajočo/neveljavno avtentikacijo).

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

## Druge bistvene stvari

```text
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
```

## Zakaj je to pomembno

Varnost je mesto, kjer majhna napaka postane vdor, zato spraševalci s tem preverijo, ali o njej sklepate strukturno in ne recitirate modnih besed. Signal, ki ga iščejo, je, da **ločite tri plasti** — transport (HTTPS, vedno), avtentikacijo (dokazovanje identitete, stateless, prek bearer tokenov/JWT/OAuth) in avtorizacijo (obsegi in najmanjši privilegij) — in da jih ne mešate, npr. pravilna raba `401` za "ni avtenticiran" proti `403` za "avtenticiran, a nima dovoljenja". Močni odgovori pokažejo zavedanje praktičnih kompromisov: JWT-ji so priročni in stateless, a jih je pred potekom težko preklicati (od tod kratke življenjske dobe plus refresh tokeni), API ključi identificirajo aplikacije, ne uporabnikov, OAuth pa obstaja prav zato, da uporabniki gesla ne izročijo tretjim osebam. Povezovanje z REST-ovo naravo stateless — poverilnice ob vsaki zahtevi, brez seje strežnika — pokaže, da razumete, *zakaj* varnost API-jev izgleda tako, kot izgleda.

Transport: vedno HTTPS

Možnosti avtentikacije

Avtorizacija: obsegi (scopes) in vloge

Druge bistvene stvari

Zakaj je to pomembno

Povezana vprašanja