Πώς λειτουργούν μαζί τα access tokens και τα refresh tokens;

Question

IT Interview Practice · Accepted Answer

Τα δύο tokens ακολουθούν έναν απλό κύκλο ζωής: ένα **βραχύβιο access token** εξουσιοδοτεί κάθε κλήση API, και ένα **μακρόβιο refresh token** παράγει σιωπηλά νέα access tokens όταν αυτά λήγουν — έτσι ο χρήστης παραμένει συνδεδεμένος χωρίς να επανεισάγει διαπιστευτήρια.

## Η ροή

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API call: Authorization: Bearer <access>
     ▼
┌────────────┐  verify signature + exp   (no DB lookup)
│ Resource   │ ──── 200 OK ────▶ (access still valid)
│ API        │ ──── 401 ───────▶ (access expired)
└────────────┘
     │  3. on 401: POST /token { refresh }
     ▼
┌────────────┐  verify + rotate
│ Auth server│ ──── new access (+ new refresh) ────▶ retry the call
└────────────┘
```

1. **Login** — ο χρήστης αυθεντικοποιείται μία φορά· ο server επιστρέφει ένα **access token** (σύντομο TTL) και ένα **refresh token** (μακρύ TTL).
2. **Πρόσβαση στα API** — ο client στέλνει το access token στο `Authorization: Bearer …` σε κάθε request. Το API το επαληθεύει stateless (υπογραφή + `exp`) και απαντά — δεν χρειάζεται session store.
3. **Refresh κατά τη λήξη** — όταν το API επιστρέφει `401` (ή ο client βλέπει ότι το `exp` πλησιάζει), ο client κάνει POST το **refresh token** στο endpoint `/token` του auth server και παίρνει ένα φρέσκο access token, και μετά επαναλαμβάνει το αρχικό request. Ο χρήστης δεν αντιλαμβάνεται τίποτα.
4. **Logout / ανάκληση** — ο server διαγράφει ή βάζει σε denylist το refresh token· το επόμενο refresh αποτυγχάνει και η συνεδρία τελειώνει (το τρέχον access token πεθαίνει ούτως ή άλλως από μόνο του μέσα σε λεπτά).

```js
// Interceptor του client: refresh μία φορά στο 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;
}
```

## Rotation του refresh token

Η βέλτιστη πρακτική είναι το **rotation**: κάθε κλήση refresh επιστρέφει ένα *νέο* refresh token και ακυρώνει το παλιό. Αν ένα παλιό (ήδη χρησιμοποιημένο) refresh token παρουσιαστεί ξανά, αυτό σηματοδοτεί κλοπή — ο server ανακαλεί ολόκληρη την οικογένεια των tokens και επιβάλλει εκ νέου login. Αυτό περιορίζει τη ζημιά ενός κλεμμένου refresh token.

## Αποθήκευση

- **Refresh token** → cookie `httpOnly`, `Secure`, `SameSite` ώστε η JavaScript (και άρα το XSS) να μην μπορεί να το διαβάσει.
- **Access token** → κρατείται στη μνήμη στον client· η σύντομη ζωή περιορίζει την έκθεση.
- Ποτέ μην βάζετε κανένα από τα δύο στο `localStorage` αν μπορείτε να το αποφύγετε — είναι αναγνώσιμο από οποιοδήποτε injected script.

## Γιατί έχει σημασία

Αυτή η ροή είναι η ραχοκοκαλιά της διαχείρισης συνεδριών σε σύγχρονα SPAs, mobile apps και API, οπότε οι συνεντευκτές περιμένουν να την ιχνηλατήσετε από άκρη σε άκρη: εκδώστε και τα δύο στο login, εξουσιοδοτήστε με το access token, κάντε διαφανές refresh κατά τη λήξη, και rotate + revoke για ασφάλεια. Το να κάνετε σωστά τις λεπτομέρειες — stateless επαλήθευση, refresh μόνο στο token endpoint, rotation με ανίχνευση επαναχρησιμοποίησης, και αποθήκευση `httpOnly` — είναι η διαφορά ανάμεσα σε μια ομαλή, ασφαλή συνεδρία και σε μία όπου ένα μόνο κλεμμένο token σημαίνει μακροχρόνια κατάληψη λογαριασμού.

Η ροή

Rotation του refresh token

Αποθήκευση

Γιατί έχει σημασία

Σχετικές ερωτήσεις