Для чего используют Refresh Token?

Для чего используют Refresh Token

Refresh Token — это специальный маркер аутентификации, который используется для получения нового Access Token без необходимости повторного ввода учётных данных (логина и пароля). Это ключевой компонент современных систем безопасности и управления сеансами.

Основная цель

Разделить аутентификацию (процесс подтверждения личности) и авторизацию (проверка прав доступа) на две части с разными сроками действия:

• Access Token — короткоживущий (5-15 минут)
• Refresh Token — долгоживущий (дни или недели)

Это обеспечивает баланс между безопасностью и удобством использования.

Архитектура с Refresh Token

Шаг 1: Начальная аутентификация

Пользователь        Сервер аутентификации
     |                        |
     |--логин/пароль-------->|
     |                   [проверка]
     |<--Access Token, Refresh Token--|
     |                        |

Шаг 2: Обычное использование API

Клиент              API Сервер
  |                     |
  |--запрос с----------->|
  | Access Token        [проверка токена]
  |<--данные------------|  
  |                     |

Шаг 3: Обновление Access Token

Клиент         Сервер аутентификации
  |                     |
  |--Refresh Token----->|
  |              [валидация]
  |<--новый Access Token--|
  |                     |

Зачем нужны два токена

1. Безопасность

Access Token имеет короткий срок действия (обычно 5-15 минут). Если токен украдён:

• Злоумышленник может использовать его только 5-15 минут
• После истечения срока он бесполезен
• Минимизируется окно уязвимости

Refresh Token хранится более безопасно и используется реже:

• Refresh Token можно хранить в HttpOnly Cookie (недоступно для JavaScript)
• Использование только при необходимости обновления
• Сложнее украсть, так как он редко передаётся

2. Удобство

Без Refresh Token пользователю пришлось бы повторно вводить логин и пароль каждые 5-15 минут. Это плохой UX.

С Refresh Token пользователь входит один раз, а система автоматически обновляет Access Token в фоне.

3. Гибкость

• Access Token можно быстро инвалидировать (отозвать)
• Refresh Token может быть отозван отдельно
• Разные сроки действия для разных типов приложений

Сценарии использования

Сценарий 1: Access Token истёк

1. Пользователь: Access Token ещё действует
   - Использует API с этим токеном
   - Всё работает

2. Спустя 10 минут: Access Token истёк
   - API возвращает 401 Unauthorized
   - Клиент видит, что токен истёк

3. Клиент отправляет Refresh Token
   - Сервер проверяет Refresh Token
   - Если валиден, выдаёт новый Access Token
   - Пользователь может продолжить работу

4. Если Refresh Token тоже истёк
   - Пользователя просят снова авторизоваться

Сценарий 2: Пользователь закрыл браузер

1. Пользователь заходит на сайт с сохранённым Refresh Token
2. Браузер использует Refresh Token для получения нового Access Token
3. Пользователь остаётся авторизованным (Single Sign-On)
4. Никакого ввода логина и пароля не требуется

Сценарий 3: Отозвание доступа

1. Администратор блокирует пользователя
2. Refresh Token помещается в чёрный список
3. При попытке обновить Access Token, сервер отказывает
4. Пользователь должен заново авторизоваться

Без Refresh Token пришлось бы ждать истечения Access Token.

Типы Refresh Token

Rotating Refresh Token (рекомендуется)

Каждый раз при обновлении Access Token выдаётся новый Refresh Token:

1. Запрос: старый Refresh Token
2. Ответ: новый Access Token + новый Refresh Token
3. Старый Refresh Token становится недействительным

Плюсы:

• Если Refresh Token украдён, после его использования он становится недействительным
• Обнаружение компрометации (клиент использует старый токен)

Минусы:

• Требует синхронизации (что, если сеть прервалась?)
• Более сложная реализация

Static Refresh Token

Refresh Token выдаётся один раз и не меняется:

1. При логине: Refresh Token (не меняется)
2. Каждое обновление: новый Access Token (тот же Refresh Token)

Плюсы:

• Простая реализация
• Отсутствие проблем с синхронизацией

Минусы:

• Если украден, может использоваться долго
• Сложнее обнаружить компрометацию

Хранение Refresh Token

В браузере (веб-приложение)

HttpOnly Cookie:

Set-Cookie: refreshToken=...; HttpOnly; Secure; SameSite=Strict

Плюсы:

• CSRF атаки менее опасны (SameSite)
• JavaScript не может получить токен
• Автоматически отправляется в запросах

Минусы:

• Уязвимость к XSS (но меньше, чем в localStorage)

В локальном хранилище (веб-приложение)

localStorage.setItem('refreshToken', token)

Плюсы:

• Не отправляется автоматически
• Контролируемое использование

Минусы:

• Уязвим к XSS атакам

В защищённом хранилище (мобильное приложение)

Keychain (iOS) или KeyStore (Android)

Плюсы:

• Защита на уровне ОС
• Невозможно получить без разрешения

Пример реализации (Node.js + JWT)

Выдача токенов при логине:

const payload = { userId: user.id, role: user.role };
const accessToken = jwt.sign(payload, SECRET, { expiresIn: '15m' });
const refreshToken = jwt.sign(payload, REFRESH_SECRET, { expiresIn: '7d' });

res.cookie('refreshToken', refreshToken, { httpOnly: true, secure: true });
res.json({ accessToken });

Обновление Access Token:

app.post('/refresh', (req, res) => {
  const { refreshToken } = req.cookies;
  
  try {
    const decoded = jwt.verify(refreshToken, REFRESH_SECRET);
    const newAccessToken = jwt.sign(
      { userId: decoded.userId, role: decoded.role },
      SECRET,
      { expiresIn: '15m' }
    );
    res.json({ accessToken: newAccessToken });
  } catch (err) {
    res.status(401).json({ error: 'Invalid refresh token' });
  }
});

Рекомендации по использованию

1. Короткий срок Access Token (5-15 минут)
2. Длительный срок Refresh Token (7-30 дней)
3. HttpOnly Cookie для Refresh Token (веб)
4. Использовать HTTPS (защита при передаче)
5. Реализовать черный список токенов (для отозвания)
6. Логировать обновления токенов (обнаружение подозрительной активности)
7. Сделать логику обновления токенов бесшумной (без раздражения пользователя)
8. Обновлять Refresh Token при каждом обновлении Access Token (Rotating Refresh Token)

Современный подход

В современных приложениях используется OAuth 2.0 и OpenID Connect, которые построены на концепции Refresh Token. Популярные платформы (Google, Facebook, GitHub) используют именно этот подход.