Si e siguron një REST API (authentication, authorization, transport)?

Question

IT Interview Practice · Accepted Answer

Sigurimi i një REST API do të thotë t'u përgjigjesh tri pyetjeve në çdo request: **kush je ti** (authentication), **çfarë të lejohet të bësh** (authorization), dhe **a është kanali privat** (transport). Meqë REST është **stateless**, credentials duhet të udhëtojnë me çdo request sesa të qëndrojnë në një session server-i.

## Transport: gjithmonë HTTPS

Gjithçka më poshtë supozon **TLS/HTTPS**. Pa të, tokens dhe API keys udhëtojnë në plaintext dhe mund të përgjohen. Kjo nuk negociohet — një bearer token mbi HTTP është një token i rrjedhur.

## Opsionet e authentication

**API keys** — një sekret statik në një header. I thjeshtë; i mirë për server-to-server dhe për të identifikuar një *aplikacion*, jo një user. I dobët në vetvete (pa skadim, pa scope) përveçse kur çiftohet me më shumë.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — standardi për qasje **të deleguar** ("lejo App X të lexojë të dhënat e mia pa fjalëkalimin tim"). Aplikacioni merr një **access token** përmes një flow (p.sh. Authorization Code) dhe e dërgon si bearer token. Kështu funksionojnë "Sign in with Google" dhe integrimet me palë të treta.

**JWT (JSON Web Token)** — një *format* i zakonshëm për tokens: një token i nënshkruar, i vetëpërmbajtur që mbart claims (user id, roles, skadim). Serveri e verifikon nënshkrimin — pa nevojë për një lookup në bazën e të dhënave, gjë që i përshtatet REST-it stateless.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Authorization: scopes dhe roles

Authentication e vërteton identitetin; **authorization** vendos qasjen. Tokens mbartin **scopes** (`orders:read`, `orders:write`) ose roles; serveri i kontrollon ato për çdo endpoint dhe kthen `403 Forbidden` kur janë të pamjaftueshme (kundrejt `401` për auth që mungon/e pavlefshme).

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

## Të tjera thelbësore

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

## Pse ka rëndësi

Siguria është vendi ku një gabim i vogël bëhet një shkelje (breach), prandaj intervistuesit e përdorin këtë për të parë nëse arsyeton rreth saj në mënyrë strukturore sesa duke recituar buzzwords. Sinjali që kërkojnë është që ti **i ndan tri shtresat** — transport (HTTPS, gjithmonë), authentication (vërtetimi i identitetit, në mënyrë stateless, përmes bearer tokens/JWT/OAuth), dhe authorization (scopes dhe least privilege) — dhe që nuk i ngatërron, p.sh. duke përdorur saktë `401` për "i paautentikuar" kundrejt `403` për "i autentikuar por i palejuar". Përgjigjet e forta tregojnë vetëdije për kompromiset praktike: JWT janë të përshtatshëm dhe stateless por të vështirë për t'u revokuar para se të skadojnë (prandaj jetëgjatësi të shkurtra plus refresh tokens), API keys identifikojnë aplikacione jo users, dhe OAuth ekziston posaçërisht që user-ët të mos ua japin fjalëkalimin palëve të treta. Ta lidhësh me statelessness-in e REST-it — credentials në çdo request, pa session server-i — tregon se e kupton *pse* siguria e API-ve duket ashtu siç është.

Transport: gjithmonë HTTPS

Opsionet e authentication

Authorization: scopes dhe roles

Të tjera thelbësore

Pse ka rëndësi

Pyetje të ngjashme