როგორ მუშაობენ access token-ები და refresh token-ები ერთად?

Question

IT Interview Practice · Accepted Answer

ორი token მარტივ სასიცოცხლო ციკლს მიჰყვება: **ხანმოკლე access token** ავტორიზებას აძლევს ყოველ API გამოძახებას, ხოლო **ხანგრძლივი refresh token** ჩუმად ჭრის ახალ access token-ებს მათი ვადის ამოწურვისას — ასე მომხმარებელი რჩება შესული ავტორიზაციის მონაცემების ხელახლა შეყვანის გარეშე.

## პროცესი

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API გამოძახება: Authorization: Bearer <access>
     ▼
┌────────────┐  ხელმოწერის + exp-ის შემოწმება   (DB-ში ძებნის გარეშე)
│ Resource   │ ──── 200 OK ────▶ (access ჯერ კიდევ ვალიდურია)
│ API        │ ──── 401 ───────▶ (access ვადაგასულია)
└────────────┘
     │  3. 401-ის შემთხვევაში: POST /token { refresh }
     ▼
┌────────────┐  შემოწმება + როტაცია
│ Auth server│ ──── ახალი access (+ ახალი refresh) ────▶ გამოძახების ხელახლა ცდა
└────────────┘
```

1. **Login** — მომხმარებელი ერთხელ ავთენტიფიცირდება; სერვერი აბრუნებს **access token**-ს (მოკლე TTL) და **refresh token**-ს (გრძელი TTL).
2. **API-ებზე წვდომა** — კლიენტი აგზავნის access token-ს `Authorization: Bearer …`-ში ყოველ მოთხოვნაზე. API ამოწმებს მას stateless-ად (ხელმოწერა + `exp`) და პასუხობს — session store არ არის საჭირო.
3. **განახლება ვადის ამოწურვისას** — როდესაც API აბრუნებს `401`-ს (ან კლიენტი ხედავს, რომ `exp` ახლოსაა), კლიენტი POST-ავს **refresh token**-ს auth სერვერის `/token` endpoint-ზე და იღებს ახალ access token-ს, შემდეგ ხელახლა ცდის თავდაპირველ მოთხოვნას. მომხმარებელი ვერაფერს ამჩნევს.
4. **გამოსვლა / გაუქმება** — სერვერი შლის ან denylist-ში ამატებს refresh token-ს; მომდევნო განახლება ვერ ხერხდება და სესია მთავრდება (მიმდინარე access token მაინც თავისით კვდება წუთებში).

```js
// კლიენტის interceptor: ერთხელ განაახლე 401-ზე, შემდეგ ხელახლა სცადე.
async function apiFetch(url, opts = {}) {
  let res = await fetch(url, withAuth(opts, accessToken));
  if (res.status === 401) {
    accessToken = await refreshAccessToken(refreshToken); // POST /token
    res = await fetch(url, withAuth(opts, accessToken));   // ხელახლა ცდა
  }
  return res;
}
```

## refresh token-ის როტაცია

საუკეთესო პრაქტიკა არის **როტაცია**: ყოველი განახლების გამოძახება აბრუნებს *ახალ* refresh token-ს და აუქმებს ძველს. თუ ძველი (უკვე გამოყენებული) refresh token ხელახლა წარდგება, ეს ქურდობაზე მიანიშნებს — სერვერი აუქმებს მთელ token-ოჯახს და აიძულებს ხელახლა შესვლას. ეს ზღუდავს მოპარული refresh token-ის ზიანს.

## შენახვა

- **Refresh token** → `httpOnly`, `Secure`, `SameSite` cookie, რომ JavaScript-მა (და შესაბამისად XSS-მა) ვერ წაიკითხოს იგი.
- **Access token** → ინახება მეხსიერებაში კლიენტზე; მოკლე სიცოცხლე ზღუდავს ექსპოზიციას.
- არცერთი ჩადოთ `localStorage`-ში, თუ შესაძლებელია აიცილოთ — მას ნებისმიერი ჩაშენებული სკრიპტი კითხულობს.

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

ეს პროცესი არის სესიების მართვის ხერხემალი თანამედროვე SPA-ებში, მობილურ აპებსა და API-ებში, ამიტომ ინტერვიუერები მოელიან, რომ თქვენ მას თავიდან ბოლომდე გაადევნებთ თვალს: ორივეს გამოშვება login-ზე, ავტორიზაცია access token-ით, გამჭვირვალე განახლება ვადის ამოწურვისას და როტაცია + გაუქმება უსაფრთხოებისთვის. დეტალების სწორად შესრულება — stateless შემოწმება, განახლება მხოლოდ token endpoint-ზე, როტაცია ხელახალი გამოყენების აღმოჩენით და `httpOnly` შენახვა — არის განსხვავება გლუვ, უსაფრთხო სესიასა და ისეთს შორის, სადაც ერთი მოპარული token ნიშნავს ხანგრძლივ ანგარიშის ხელში ჩაგდებას.

პროცესი

refresh token-ის როტაცია

შენახვა

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

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