Come proteggi un’API REST (autenticazione, autorizzazione, trasporto)?

Question

IT Interview Practice · Accepted Answer

Proteggere un'API REST significa rispondere a tre domande a ogni richiesta: **chi sei** (autenticazione), **cosa ti è permesso fare** (autorizzazione), e **il canale è privato** (trasporto). Poiché REST è **stateless**, le credenziali devono viaggiare con ogni richiesta anziché vivere in una sessione server.

## Trasporto: sempre HTTPS

Tutto quanto segue presuppone **TLS/HTTPS**. Senza di esso, token e API key viaggiano in chiaro e possono essere intercettati. Questo non è negoziabile — un bearer token su HTTP è un token trapelato.

## Opzioni di autenticazione

**API key** — un segreto statico in un header. Semplice; buona per server-to-server e per identificare un'*applicazione*, non un utente. Debole da sola (nessuna scadenza, nessuno scope) a meno che non sia abbinata ad altro.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — lo standard per l'accesso **delegato** ("lascia che l'App X legga i miei dati senza la mia password"). L'app ottiene un **access token** tramite un flow (es. Authorization Code) e lo invia come bearer token. È così che funzionano "Sign in with Google" e le integrazioni di terze parti.

**JWT (JSON Web Token)** — un *formato* comune per i token: un token firmato e auto-contenuto che porta claim (user id, ruoli, scadenza). Il server verifica la firma — nessuna lookup su database necessaria, il che si adatta a REST stateless.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Autorizzazione: scope e ruoli

L'autenticazione prova l'identità; l'**autorizzazione** decide l'accesso. I token portano **scope** (`orders:read`, `orders:write`) o ruoli; il server li controlla per ogni endpoint e restituisce `403 Forbidden` quando sono insufficienti (vs `401` per auth mancante/non valida).

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

## Altri elementi essenziali

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

## Perché è importante

La sicurezza è dove un piccolo errore diventa una violazione, quindi gli intervistatori la usano per vedere se ci ragioni in modo strutturale anziché recitare buzzword. Il segnale che cercano è che tu **separi i tre strati** — trasporto (HTTPS, sempre), autenticazione (provare l'identità, in modo stateless, tramite bearer token/JWT/OAuth) e autorizzazione (scope e minimo privilegio) — e che non li confonda, es. usando correttamente `401` per "non autenticato" rispetto a `403` per "autenticato ma non autorizzato". Le risposte forti mostrano consapevolezza dei compromessi pratici: i JWT sono comodi e stateless ma difficili da revocare prima che scadano (da cui vite brevi più refresh token), le API key identificano app non utenti, e OAuth esiste proprio perché gli utenti non consegnino la loro password a terze parti. Legarlo alla statelessness di REST — credenziali a ogni richiesta, nessuna sessione server — mostra che capisci *perché* la sicurezza delle API ha l'aspetto che ha.

Trasporto: sempre HTTPS

Opzioni di autenticazione

Autorizzazione: scope e ruoli

Altri elementi essenziali

Perché è importante

Domande correlate