Как access-токены и refresh-токены работают вместе?

Question

IT Interview Practice · Accepted Answer

Оба токена следуют простому жизненному циклу: **короткоживущий access-токен** авторизует каждый вызов API, а **долгоживущий refresh-токен** незаметно чеканит новые access-токены, когда те истекают — так пользователь остаётся в системе без повторного ввода учётных данных.

## Поток

```
┌─────────┐  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-токен** (короткий TTL) и **refresh-токен** (долгий TTL).
2. **Доступ к API** — клиент отправляет access-токен в `Authorization: Bearer …` при каждом запросе. API проверяет его без состояния (подпись + `exp`) и отвечает — хранилище сессий не нужно.
3. **Обновление при истечении** — когда API возвращает `401` (или клиент видит, что `exp` близко), клиент делает POST **refresh-токена** на эндпоинт `/token` сервера аутентификации и получает свежий access-токен, затем повторяет исходный запрос. Пользователь ничего не замечает.
4. **Logout / отзыв** — сервер удаляет или добавляет refresh-токен в denylist; следующее обновление не удаётся, и сессия завершается (текущий access-токен всё равно сам умирает в течение минут).

```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-токена

Лучшая практика — **ротация**: каждый вызов обновления возвращает *новый* refresh-токен и аннулирует старый. Если старый (уже использованный) refresh-токен предъявляется снова, это сигнализирует о краже — сервер отзывает всё семейство токенов и вынуждает повторный вход. Это ограничивает ущерб от украденного refresh-токена.

## Хранение

- **Refresh-токен** → cookie `httpOnly`, `Secure`, `SameSite`, чтобы JavaScript (а значит, и XSS) не мог его прочитать.
- **Access-токен** → хранится в памяти на клиенте; короткая жизнь ограничивает раскрытие.
- Никогда не помещайте ни один из них в `localStorage`, если можете этого избежать — он читается любым внедрённым скриптом.

## Почему это важно

Этот поток — основа управления сессиями в современных SPA, мобильных приложениях и API, поэтому интервьюеры ожидают, что вы проследите его от начала до конца: выдать оба при входе, авторизовать access-токеном, прозрачно обновлять при истечении и ротировать + отзывать ради безопасности. Правильные детали — проверка без состояния, обновление только на token-эндпоинте, ротация с обнаружением повторного использования и хранение `httpOnly` — это разница между плавной, безопасной сессией и той, где один украденный токен означает долгосрочный захват аккаунта.

Поток

Ротация refresh-токена

Хранение

Почему это важно

Похожие вопросы