Kako osigurati REST API (autentikacija, autorizacija, transport)?

Question

IT Interview Practice · Accepted Answer

Osiguravanje REST API-ja znači odgovoriti na tri pitanja pri svakom zahtjevu: **tko si ti** (autentikacija), **što smiješ raditi** (autorizacija) i **je li kanal privatan** (transport). Budući da je REST **stateless**, vjerodajnice moraju putovati sa svakim zahtjevom umjesto da žive u serverskoj sesiji.

## Transport: uvijek HTTPS

Sve u nastavku pretpostavlja **TLS/HTTPS**. Bez njega, tokeni i API ključevi putuju u plaintextu i mogu se prisluškivati. To je neupitno — bearer token preko HTTP-a je procureli token.

## Opcije autentikacije

**API ključevi** — statička tajna u headeru. Jednostavno; dobro za server-to-server i identifikaciju *aplikacije*, ne korisnika. Slabi sami po sebi (bez isteka, bez scopea) osim ako se uparuju s više.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — standard za **delegirani** pristup ("neka App X čita moje podatke bez moje lozinke"). Aplikacija dobiva **access token** kroz flow (npr. Authorization Code) i šalje ga kao bearer token. Tako rade "Sign in with Google" i integracije trećih strana.

**JWT (JSON Web Token)** — čest *format* za tokene: potpisan, samostalan token koji nosi claimove (user id, uloge, istek). Server provjerava potpis — bez potrebe za pretragom baze, što pristaje statelessnom REST-u.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Autorizacija: scopeovi i uloge

Autentikacija dokazuje identitet; **autorizacija** odlučuje o pristupu. Tokeni nose **scopeove** (`orders:read`, `orders:write`) ili uloge; server ih provjerava po endpointu i vraća `403 Forbidden` kad su nedostatni (naspram `401` za nedostajući/nevaljani auth).

```text
Nema/nevaljani token      → 401 Unauthorized
Valjani token, bez scopea → 403 Forbidden
```

## Ostalo bitno

```text
✓ Kratkotrajni access tokeni + refresh tokeni (ograniči domet štete ako procure)
✓ Rate limiting (429) za otupljivanje brute-forcea i zloupotrebe
✓ Validirajte/sanitizirajte sav ulaz; nikad ne vjerujte klijentu
✓ Načelo najmanje privilegije (least privilege) na scopeovima
```

## Zašto je to važno

Sigurnost je mjesto gdje mala greška postaje proboj, pa ispitivači ovim gledaju razmišljate li o njoj strukturno umjesto recitiranja buzzworda. Signal koji traže jest da **razdvajate tri sloja** — transport (HTTPS, uvijek), autentikacija (dokazivanje identiteta, stateless, preko bearer tokena/JWT/OAuth) i autorizacija (scopeovi i najmanja privilegija) — i da ih ne miješate, npr. ispravno koristeći `401` za "nije autenticirano" naspram `403` za "autenticirano, ali nije dopušteno". Snažni odgovori pokazuju svijest o praktičnim kompromisima: JWT-ovi su praktični i stateless, ali ih je teško opozvati prije isteka (otud kratki životni vijek plus refresh tokeni), API ključevi identificiraju aplikacije, a ne korisnike, a OAuth postoji upravo zato da korisnici ne predaju svoju lozinku trećim stranama. Povezivanje s REST-ovom statelessnošću — vjerodajnice pri svakom zahtjevu, bez serverske sesije — pokazuje da razumijete *zašto* sigurnost API-ja izgleda kako izgleda.

Transport: uvijek HTTPS

Opcije autentikacije

Autorizacija: scopeovi i uloge

Ostalo bitno

Zašto je to važno

Povezana pitanja