როგორ დაიცავ REST API-ს (authentication, authorization, transport)?

Question

IT Interview Practice · Accepted Answer

REST API-ის დაცვა ნიშნავს სამ კითხვაზე პასუხს ყოველ request-ზე: **შენ ვინ ხარ** (authentication), **რის უფლება გაქვს** (authorization), და **არის თუ არა არხი კონფიდენციალური** (transport). რადგან REST **stateless**-ია, credential-ები ყოველ request-თან ერთად უნდა მოგზაურობდნენ და არა server-ის session-ში ცხოვრობდნენ.

## Transport: ყოველთვის HTTPS

ყველაფერი ქვემოთ ვარაუდობს **TLS/HTTPS**-ს. მის გარეშე token-ები და API key-ები plaintext-ში მოგზაურობენ და შესაძლებელია მათი მოსმენა. ეს არაგანსახილველია — bearer token HTTP-ზე გაჟონილი token-ია.

## Authentication-ის ვარიანტები

**API key-ები** — სტატიკური საიდუმლო header-ში. მარტივი; კარგია server-to-server-ისთვის და *აპლიკაციის* იდენტიფიცირებისთვის, არა user-ის. თავისთავად სუსტი (ვადა არ აქვს, scope არ აქვს), თუ მეტთან არ დაწყვილდა.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — სტანდარტი **დელეგირებული** წვდომისთვის („მიეცი App X-ს ჩემი მონაცემების წაკითხვის უფლება ჩემი პაროლის გარეშე"). აპლიკაცია იღებს **access token-ს** flow-ის მეშვეობით (მაგ. Authorization Code) და აგზავნის მას როგორც bearer token-ს. ასე მუშაობს „Sign in with Google" და მესამე მხარის ინტეგრაციები.

**JWT (JSON Web Token)** — token-ების გავრცელებული *ფორმატი*: ხელმოწერილი, თვითკმარი token, რომელიც ატარებს claim-ებს (user id, role-ები, ვადა). server ამოწმებს ხელმოწერას — database-ის ძებნა არ სჭირდება, რაც stateless REST-ს ერგება.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Authorization: scope-ები და role-ები

Authentication ამტკიცებს იდენტობას; **authorization** წყვეტს წვდომას. token-ები ატარებენ **scope-ებს** (`orders:read`, `orders:write`) ან role-ებს; server ამოწმებს მათ თითო endpoint-ზე და აბრუნებს `403 Forbidden`-ს, როცა ისინი არასაკმარისია (vs `401` აკლია/არასწორი auth-ისთვის).

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

## სხვა აუცილებელი

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

## რატომ არის ეს მნიშვნელოვანი

უსაფრთხოება არის ის, სადაც პატარა შეცდომა breach-ად იქცევა, ამიტომ ინტერვიუერები ამას იყენებენ იმის სანახავად, სტრუქტურულად მსჯელობთ თუ არა მასზე და არა buzzword-ებს იმეორებთ. სიგნალი, რომელსაც ისინი ეძებენ, არის ის, რომ თქვენ **ჰყოფთ სამ ფენას** — transport (HTTPS, ყოველთვის), authentication (იდენტობის დამტკიცება, stateless-ად, bearer token-ების/JWT/OAuth-ის მეშვეობით) და authorization (scope-ები და least privilege) — და არ ურევთ მათ, მაგ. სწორად იყენებთ `401`-ს „არააუთენტიფიცირებულისთვის" vs `403`-ს „აუთენტიფიცირებული, მაგრამ ნებადაურთველისთვის". ძლიერი პასუხები აჩვენებენ პრაქტიკული ტრეიდ-ოფების ცოდნას: JWT-ები მოსახერხებელი და stateless-ია, მაგრამ ვადის გასვლამდე მათი გაუქმება რთულია (აქედან მოკლე სიცოცხლე პლუს refresh token-ები), API key-ები აპლიკაციებს აიდენტიფიცირებენ და არა user-ებს, და OAuth სწორედ იმისთვის არსებობს, რომ მომხმარებლებმა თავიანთი პაროლი მესამე მხარეს არ ჩააბარონ. ამის REST-ის statelessness-თან დაკავშირება — credential-ები ყოველ request-ზე, server-ის session-ის გარეშე — აჩვენებს, რომ გესმით *რატომ* გამოიყურება API-ის უსაფრთხოება ისე, როგორც გამოიყურება.

Transport: ყოველთვის HTTPS

Authentication-ის ვარიანტები

Authorization: scope-ები და role-ები

სხვა აუცილებელი

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები