Skip to content
EN

Что такое Refresh Token

Коротко:

Refresh token — долгоживущий токен (недели/месяцы), который client использует для получения новых коротких access_token без повторной аутентификации. Типичный flow: access_token живёт 15 мин, refresh_token 30 дней. Когда access истёк, клиент шлёт refresh к token endpoint → получает новый access. Критично: refresh хранить в secure storage (httpOnly cookie, не localStorage).

Ниже: подробности, пример, смежные термины, FAQ.

Проверить безопасность сайта →

Подробности

  • Access token: short-lived (5-15 min), передаётся в каждом запросе
  • Refresh token: long-lived (30+ days), только на token endpoint
  • Rotation: при use refresh выдаётся новый refresh, старый revoked
  • Revocation list: Redis/DB со списком invalidated tokens
  • Грэйсовых период: 30 сек на race conditions при concurrent refreshes

Пример

POST /oauth/token
  grant_type=refresh_token
  refresh_token=XXX
  client_id=Y
→ { access_token: "...", refresh_token: "NEW", expires_in: 900 }

Смежные термины

Что такое Refresh Token?

Refresh Token — это специальный токен, используемый в протоколах аутентификации для получения новых access-токенов без повторного ввода учетных данных пользователем. Он позволяет поддерживать сессию активной, даже если access-токен истек, что особенно важно для приложений с ограниченным временем действия токенов, обычно составляющим от 15 до 60 минут.

Как работает Refresh Token?

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

Процесс работы refresh-токена выглядит следующим образом:

  1. Пользователь аутентифицируется и получает access-токен и refresh-токен.
  2. При истечении срока действия access-токена приложение отправляет запрос на сервер с использованием refresh-токена.
  3. Сервер проверяет действительность refresh-токена и, если он действителен, выдает новый access-токен.

Для реализации этого механизма можно использовать HTTP-запросы. Например, с помощью команды curl:

curl -X POST https://api.example.com/token/refresh \
-H "Content-Type: application/json" \
-d '{"refresh_token": "your_refresh_token"}'

Если refresh-токен действителен, сервер вернет новый access-токен в ответе.

Примеры использования Refresh Token

Refresh Token широко используется в веб-приложениях и мобильных приложениях для поддержания сессий пользователей. Например, при разработке RESTful API можно использовать refresh-токены для аутентификации пользователей. Ниже представлен пример реализации на Node.js с использованием библиотеки jsonwebtoken:

const jwt = require('jsonwebtoken');
const refreshTokens = [];

app.post('/login', (req, res) => {
    // Аутентификация пользователя
    const user = { id: 1 }; // пример пользователя
    const accessToken = jwt.sign(user, process.env.ACCESS_TOKEN_SECRET, { expiresIn: '15m' });
    const refreshToken = jwt.sign(user, process.env.REFRESH_TOKEN_SECRET);
    refreshTokens.push(refreshToken);
    res.json({ accessToken, refreshToken });
});

app.post('/token', (req, res) => {
    const { token } = req.body;
    if (!token) return res.sendStatus(401);
    if (!refreshTokens.includes(token)) return res.sendStatus(403);
    jwt.verify(token, process.env.REFRESH_TOKEN_SECRET, (err, user) => {
        if (err) return res.sendStatus(403);
        const accessToken = jwt.sign({ id: user.id }, process.env.ACCESS_TOKEN_SECRET, { expiresIn: '15m' });
        res.json({ accessToken });
    });
});

В этом примере, после успешной аутентификации пользователь получает access-токен и refresh-токен. Когда access-токен истекает, пользователь может запросить новый access-токен, отправив refresh-токен на сервер.

ЗаголовкиCSP, HSTS, X-Frame-Options и др.
SSL/TLSШифрование и сертификат
КонфигурацияСерверные настройки и утечки
Оценка A-FОбщий балл безопасности

Почему нам доверяют

OWASP
рекомендации
15+
заголовков безопасности
<2с
результат
A–F
оценка безопасности

Как это работает

1

Введите URL сайта

2

Анализ заголовков безопасности

3

Получите оценку A–F

Что проверяет анализ безопасности?

Инструмент проверяет HTTP-заголовки безопасности, конфигурацию SSL/TLS, утечки серверной информации и защиту от распространённых атак (XSS, clickjacking, MIMEsniffing). Оценка от A до F показывает общий уровень защиты.

Анализ заголовков

Проверка Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy и других.

Проверка SSL

Версия TLS, срок сертификата, цепочка доверия, поддержка HSTS.

Обнаружение утечек

Поиск раскрытых серверных версий, debug-режимов, открытых конфигов и директорий.

Отчёт с рекомендациями

Детальный отчёт с объяснением каждой проблемы и конкретными шагами для исправления.

Кому это нужно

Специалисты по безопасности

аудит HTTP-заголовков

DevOps

проверка конфигурации

Разработчики

CSP и HSTS настройка

Аудиторы

соответствие стандартам

Частые ошибки

Нет Content-Security-PolicyCSP — главная защита от XSS. Без него инъекция скриптов значительно проще.
Нет заголовка HSTSБез HSTS возможна downgrade-атака с HTTPS на HTTP. Включите Strict-Transport-Security.
Server header раскрывает версиюServer: Apache/2.4.52 помогает атакующим подобрать эксплойт. Скройте версию.
X-Frame-Options не установленСайт можно встроить в iframe для clickjacking-атаки. Установите DENY или SAMEORIGIN.
Нет X-Content-Type-OptionsБез nosniff браузер может интерпретировать файлы неправильно (MIME sniffing).

Лучшие практики

Начните с базовых заголовковМинимум: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Займёт 5 минут.
Внедрите CSP постепенноНачните с Content-Security-Policy-Report-Only, мониторьте нарушения, затем включите.
Скройте серверные заголовкиУдалите Server, X-Powered-By, X-AspNet-Version из ответов.
Настройте Permissions-PolicyОграничьте доступ к камере, микрофону, геолокации — только то, что реально используется.
Проверяйте после каждого деплояЗаголовки безопасности могут быть перезаписаны при обновлении конфигурации сервера.

Получите больше с бесплатным аккаунтом

История security-проверок и мониторинг HTTP-заголовков безопасности.

Зарегистрироваться (FREE)

Больше по теме

Часто задаваемые вопросы

Где хранить refresh token?

Server-side: session/database. Client-side: httpOnly + Secure + SameSite=Strict cookie. Никогда localStorage — XSS vulnerability.

Что делать при подозрении utечки?

Revoke all refresh tokens user через <code>DELETE /tokens WHERE user_id=X</code>. User должен relogin.

Refresh rotation — обязательно?

Best practice. Особенно для SPA. OAuth 2.1 draft требует rotation.

Запустить инструмент, который описан в этой статье

Бесплатный тариф — 10 мониторов, проверки каждые 5 мин, без карты. Платные тарифы — интервал от 1 минуты и проверки из нескольких регионов.