Kaip apsaugoti REST API (autentifikacija, autorizacija, transportas)?

Question

IT Interview Practice · Accepted Answer

REST API apsauga reiškia atsakyti į tris klausimus kiekvienoje užklausoje: **kas tu esi** (authentication), **ką tau leidžiama daryti** (authorization) ir **ar kanalas privatus** (transport). Kadangi REST yra **stateless**, credentials turi keliauti su kiekviena užklausa, o ne gyventi serverio sesijoje.

## Transportas: visada HTTPS

Viskas žemiau daro prielaidą, kad yra **TLS/HTTPS**. Be jo tokenai ir API keys keliauja atviru tekstu ir gali būti perimti. Tai neaptariama — bearer token per HTTP yra nutekintas token.

## Autentifikacijos parinktys

**API keys** — statinis slaptažodis header. Paprasta; gerai server-to-server ir *programai* identifikuoti, o ne naudotojui. Silpna savaime (nėra galiojimo, nėra scope), nebent poruojama su daugiau.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — standartas **deleguotai** prieigai („leisk App X skaityti mano duomenis be mano slaptažodžio“). Programa gauna **access token** per flow (pvz. Authorization Code) ir siunčia jį kaip bearer token. Taip veikia „Sign in with Google“ ir trečiųjų šalių integracijos.

**JWT (JSON Web Token)** — dažnas tokenų *formatas*: pasirašytas, savaime pakankamas tokenas, nešantis claims (user id, roles, expiry). Serveris patikrina parašą — nereikia kreiptis į duomenų bazę, o tai tinka stateless REST.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Autorizacija: scopes ir roles

Autentifikacija įrodo tapatybę; **autorizacija** sprendžia prieigą. Tokenai neša **scopes** (`orders:read`, `orders:write`) ar roles; serveris tikrina juos kiekvienam endpoint ir grąžina `403 Forbidden`, kai jų nepakanka (skirtingai nuo `401`, skirto trūkstamai/negaliojančiai auth).

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

## Kiti esminiai dalykai

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

## Kodėl tai svarbu

Saugumas yra vieta, kur maža klaida tampa pažeidimu, todėl interviuotojai naudoja tai pamatyti, ar samprotaujate apie jį struktūriškai, o ne kartojate madingus žodžius. Signalas, kurio jie ieško, yra tai, kad **atskiriate tris sluoksnius** — transport (HTTPS, visada), authentication (tapatybės įrodymas, be būsenos, per bearer tokens/JWT/OAuth) ir authorization (scopes ir least privilege) — ir jų nesumaišote, pvz. teisingai naudojate `401` „neautentifikuota“ prieš `403` „autentifikuota, bet neleidžiama“. Stiprūs atsakymai rodo praktinių kompromisų suvokimą: JWT patogūs ir stateless, bet sunkiai atšaukiami prieš galiojimo pabaigą (todėl trumpi gyvavimo laikai plius refresh tokens), API keys identifikuoja programas, o ne naudotojus, ir OAuth egzistuoja būtent tam, kad naudotojai neatiduotų savo slaptažodžio trečiosioms šalims. Susiejimas su REST statelessness — credentials kiekvienoje užklausoje, jokios serverio sesijos — rodo, kad suprantate, *kodėl* API saugumas atrodo taip, kaip atrodo.

Transportas: visada HTTPS

Autentifikacijos parinktys

Autorizacija: scopes ir roles

Kiti esminiai dalykai

Kodėl tai svarbu

Susiję klausimai