Miten turvaat REST API:n (autentikointi, autorisointi, transport)?

Question

IT Interview Practice · Accepted Answer

REST API:n turvaaminen tarkoittaa kolmen kysymyksen vastaamista jokaisella pyynnöllä: **kuka olet** (authentication), **mitä saat tehdä** (authorization) ja **onko kanava yksityinen** (transport). Koska REST on **stateless**, tunnistetietojen on kuljettava jokaisen pyynnön mukana sen sijaan että ne eläisivät palvelinsessiossa.

## Transport: aina HTTPS

Kaikki alla oleva olettaa **TLS/HTTPS**:n. Ilman sitä tokenit ja API-avaimet kulkevat selkokielisenä ja ne voidaan nuuskia. Tämä ei ole neuvoteltavissa — bearer token HTTP:n yli on vuotanut token.

## Autentikointivaihtoehdot

**API-avaimet** — staattinen salaisuus headerissa. Yksinkertainen; hyvä server-to-serverille ja *sovelluksen*, ei käyttäjän, tunnistamiseen. Yksinään heikko (ei vanhenemista, ei scopea), ellei yhdistetä muuhun.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — standardi **delegoituun** pääsyyn ("anna App X:n lukea dataani ilman salasanaani"). Sovellus hankkii **access tokenin** flow'n kautta (esim. Authorization Code) ja lähettää sen bearer tokenina. Näin "Sign in with Google" ja kolmannen osapuolen integraatiot toimivat.

**JWT (JSON Web Token)** — yleinen *muoto* tokeneille: allekirjoitettu, itsenäinen token, joka kantaa claimeja (user id, roolit, vanheneminen). Palvelin verifioi allekirjoituksen — ei tietokantahakua tarvita, mikä sopii statelessiin REST:iin.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Authorization: scopet ja roolit

Autentikointi todistaa identiteetin; **authorization** päättää pääsyn. Tokenit kantavat **scopeja** (`orders:read`, `orders:write`) tai rooleja; palvelin tarkistaa ne per endpoint ja palauttaa `403 Forbidden`, kun ne ovat riittämättömät (vs. `401` puuttuvalle/epäkelvolle autentikoinnille).

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

## Muut olennaiset

```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
```

## Miksi se on tärkeää

Tietoturva on paikka, jossa pienestä virheestä tulee tietomurto, joten haastattelijat käyttävät tätä nähdäkseen, päätteletkö siitä rakenteellisesti etkä lausu muotisanoja. Signaali, jota he etsivät, on että **erotat kolme kerrosta** — transport (HTTPS, aina), authentication (identiteetin todistaminen, statelessisti, bearer tokenien/JWT/OAuth:n kautta) ja authorization (scopet ja least privilege) — etkä sekoita niitä, esim. käytät oikein `401`:tä "ei autentikoitu" ja `403`:a "autentikoitu mutta ei sallittu". Vahvat vastaukset osoittavat tietoisuutta käytännön kompromisseista: JWT:t ovat käteviä ja statelessejä mutta vaikeita peruuttaa ennen vanhenemista (siksi lyhyet elinajat plus refresh tokenit), API-avaimet tunnistavat sovelluksia eivät käyttäjiä, ja OAuth on olemassa nimenomaan siksi, ettei käyttäjien tarvitse antaa salasanaansa kolmansille osapuolille. Sen kytkeminen REST:in statelessyyteen — tunnistetiedot jokaisella pyynnöllä, ei palvelinsessiota — osoittaa, että ymmärrät *miksi* API-tietoturva näyttää siltä miltä se näyttää.

Transport: aina HTTPS

Autentikointivaihtoehdot

Authorization: scopet ja roolit

Muut olennaiset

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset