Cum securizezi un REST API (autentificare, autorizare, transport)?

Question

IT Interview Practice · Accepted Answer

Securizarea unui REST API înseamnă a răspunde la trei întrebări la fiecare cerere: **cine ești** (authentication), **ce ai voie să faci** (authorization) și **canalul este privat** (transport). Pentru că REST este **stateless**, credențialele trebuie să călătorească cu fiecare cerere, nu să trăiască într-o sesiune de server.

## Transport: mereu HTTPS

Tot ce urmează presupune **TLS/HTTPS**. Fără el, token-urile și API key-urile călătoresc în text simplu și pot fi interceptate. Este non-negociabil — un bearer token peste HTTP este un token scurs.

## Opțiuni de autentificare

**API key-uri** — un secret static într-un header. Simplu; bun pentru server-to-server și pentru identificarea unei *aplicații*, nu a unui utilizator. Slab de unul singur (fără expirare, fără scope) decât dacă e împerecheat cu mai mult.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — standardul pentru acces **delegat** („lasă App X să-mi citească datele fără parola mea"). Aplicația obține un **access token** printr-un flow (ex. Authorization Code) și îl trimite ca bearer token. Așa funcționează „Sign in with Google" și integrările terțe.

**JWT (JSON Web Token)** — un *format* comun pentru token-uri: un token semnat, auto-conținut, care poartă claim-uri (user id, roluri, expirare). Serverul verifică semnătura — fără căutare în baza de date, ceea ce se potrivește cu REST stateless.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Autorizare: scope-uri și roluri

Autentificarea dovedește identitatea; **autorizarea** decide accesul. Token-urile poartă **scope-uri** (`orders:read`, `orders:write`) sau roluri; serverul le verifică per endpoint și returnează `403 Forbidden` când sunt insuficiente (vs `401` pentru auth lipsă/invalidă).

```text
Token absent/invalid       → 401 Unauthorized
Token valid, fără scope    → 403 Forbidden
```

## Alte lucruri esențiale

```text
✓ Access token-uri de scurtă durată + refresh token-uri (limitează raza de impact dacă se scurg)
✓ Rate limiting (429) pentru a atenua brute-force și abuzul
✓ Validează/sanitizează tot input-ul; nu te încrede niciodată în client
✓ Principiul privilegiului minim pe scope-uri
```

## De ce contează

Securitatea este locul unde o greșeală mică devine o breșă, așa că intervievatorii folosesc asta pentru a vedea dacă raționezi despre ea structural, nu recitând buzzword-uri. Semnalul pe care îl caută este că **separi cele trei straturi** — transport (HTTPS, mereu), autentificare (dovedirea identității, stateless, prin bearer token-uri/JWT/OAuth) și autorizare (scope-uri și privilegiu minim) — și că nu le confunzi, ex. folosind corect `401` pentru „neautentificat" față de `403` pentru „autentificat, dar fără permisiune". Răspunsurile bune arată conștientizarea compromisurilor practice: JWT-urile sunt convenabile și stateless, dar greu de revocat înainte să expire (de aici durate scurte plus refresh token-uri), API key-urile identifică aplicații nu utilizatori, iar OAuth există tocmai pentru ca utilizatorii să nu-și dea parola unor terți. Legarea de statelessness-ul REST — credențiale la fiecare cerere, fără sesiune de server — arată că înțelegi *de ce* securitatea API arată așa cum arată.

Transport: mereu HTTPS

Opțiuni de autentificare

Autorizare: scope-uri și roluri

Alte lucruri esențiale

De ce contează

Întrebări conexe