Kif tissikura REST API (awtentikazzjoni, awtorizzazzjoni, trasport)?

Question

IT Interview Practice · Accepted Answer

Li tissikura REST API tfisser li twieġeb tliet mistoqsijiet f'kull request: **min int** (authentication), **x'inti permess tagħmel** (authorization), u **il-kanal huwa privat** (transport). Peress li REST huwa **stateless**, il-credentials iridu jivvjaġġaw ma' kull request aktar milli jgħixu f'session tas-server.

## Trasport: dejjem HTTPS

Kollox hawn taħt jassumi **TLS/HTTPS**. Mingħajru, it-tokens u l-API keys jivvjaġġaw f'plaintext u jistgħu jiġu sniffed. Dan mhux negozjabbli — bearer token fuq HTTP huwa token li nkixef.

## Għażliet ta' awtentikazzjoni

**API keys** — sigriet statiku f'header. Sempliċi; tajjeb għal server-to-server u biex jidentifika *applikazzjoni*, mhux user. Dgħajjef waħdu (ebda skadenza, ebda scope) sakemm ma jiġix imqabbel ma' aktar.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — l-istandard għal aċċess **delegat** ("ħalli lil App X taqra d-data tiegħi mingħajr il-password tiegħi"). L-app tikseb **access token** permezz ta' flow (eż. Authorization Code) u tibagħtu bħala bearer token. Hekk jaħdmu "Sign in with Google" u l-integrazzjonijiet ta' partijiet terzi.

**JWT (JSON Web Token)** — *format* komuni għat-tokens: token iffirmat u self-contained li jġorr claims (user id, roles, skadenza). Is-server jivverifika l-firma — ebda lookup fid-database mhu meħtieġ, li jaqbel ma' REST stateless.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Awtorizzazzjoni: scopes u roles

L-awtentikazzjoni tipprova l-identità; l-**awtorizzazzjoni** tiddeċiedi l-aċċess. It-tokens iġorru **scopes** (`orders:read`, `orders:write`) jew roles; is-server jiċċekkjahom għal kull endpoint u jirritorna `403 Forbidden` meta ma jkunux biżżejjed (vs `401` għal auth nieqes/invalidu).

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

## Essenzjali oħra

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

## Għaliex huwa importanti

Is-sigurtà hija fejn żball żgħir isir breach, u għalhekk l-intervistaturi jużaw dan biex jaraw jekk tirraġunax dwaru strutturalment aktar milli tirreċta buzzwords. Is-sinjal li jfittxu huwa li **tissepara t-tliet saffi** — transport (HTTPS, dejjem), authentication (tipprova l-identità, b'mod stateless, permezz ta' bearer tokens/JWT/OAuth), u authorization (scopes u least privilege) — u li ma tħawwadhomx, eż. billi tuża korrettament `401` għal "mhux awtentikat" versus `403` għal "awtentikat imma mhux permess." Tweġibiet b'saħħithom juru għarfien tat-trade-offs prattiċi: il-JWTs huma konvenjenti u stateless imma diffiċli biex tirrevokahom qabel ma jiskadu (u għalhekk ħajjiet qosra flimkien ma' refresh tokens), l-API keys jidentifikaw apps mhux users, u OAuth jeżisti speċifikament biex l-users ma jagħtux il-password tagħhom lil partijiet terzi. Li torbtu mal-istatelessness ta' REST — credentials f'kull request, ebda session tas-server — juri li tifhem *għaliex* is-sigurtà tal-API tidher kif tidher.

Trasport: dejjem HTTPS

Għażliet ta' awtentikazzjoni

Awtorizzazzjoni: scopes u roles

Essenzjali oħra

Għaliex huwa importanti

Mistoqsijiet relatati