Перейти на PRO

Что такое Refresh Token в механизме аутентификации JWT?

Тип вопроса: Безопасность Вероятность: 24% Категория: PHP Разработчик

Ответ

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

Архитектура и поток работы:

  1. Первая аутентификация: Пользователь логинится, сервер возвращает:

    • Access Token (JWT): Короткоживущий (15-30 мин.), содержит claims (например, user_id, roles), подписан. Клиент отправляет его в заголовке Authorization: Bearer <token> для доступа к API.
    • Refresh Token: Долгоживущий (дни, недели), случайная строка, хранится только на сервере (в БД или кэше) в связке с идентификатором пользователя.

  2. Обновление: Когда Access Token истекает, клиент отправляет Refresh Token на специальный эндпоинт (/auth/refresh). Сервер:

    • Проверяет его наличие и валидность в своём хранилище.
    • Инвалидирует старый Refresh Token (удаляет из БД).
    • Генерирует и возвращает новую пару Access/Refresh токенов.

Пример кода (псевдокод логики на стороне сервера):

# Эндпоинт /auth/refresh
def refresh_token_endpoint(refresh_token_from_client):
    # 1. Поиск и проверка токена в БД
    token_record = db.find_refresh_token(refresh_token_from_client)
    if not token_record or token_record.expired:
        return 401, "Invalid refresh token"

    # 2. Инвалидация использованного токена
    db.delete_refresh_token(refresh_token_from_client)

    # 3. Генерация новой пары
    user_id = token_record.user_id
    new_access_token = create_jwt(user_id, expires_in='15m')
    new_refresh_token = generate_secure_random_string()
    db.save_refresh_token(user_id, new_refresh_token, expires_in='7d')

    # 4. Отправка новой пары клиенту
    return {
        "access_token": new_access_token,
        "refresh_token": new_refresh_token
    }

Зачем это нужно? Без Refresh Token пришлось бы либо делать Access Token долгоживущим (опасно при утечке), либо заставлять пользователя логиниться каждые 15 минут. Refresh Token позволяет отозвать доступ (удалив его на сервере) и минимизирует время жизни основного Access Token.

Ответ 18+ 🔞

А, ну это ж классика, ебать мои старые костыли! Сейчас объясню на пальцах, без всей этой заумной пыли.

Смотри, есть у тебя два ключа от одного и того же сейфа с пивком. Первый ключ — Access Token — это как твой повседневный ключ от квартиры. Короткий, удобный, носишь его в кармане. Но если ты его обронишь где-то в баре, любой мудак может им воспользоваться и вынести из твоей хаты всё, вплоть до трусов. Поэтому он живёт недолго, минут 15-30, и потом превращается в тыкву.

А второй ключ — Refresh Token — это как запасной ключ, который ты засунул в тайник под ковриком. Он один, долгоживущий (дни, недели), и нужен только для одной, ёпта, цели: если твой повседневный ключ (Access Token) сдох, ты этим запасным идёшь в специальную конторку (/auth/refresh), говоришь «эй, дайте мне новый комплект», и тебе выдают свежий Access Token и, внимание, новый запасной Refresh Token. Старый запасной при этом они у тебя забирают и уничтожают. Хитрая жопа, да?

Как это выглядит в жизни:

  1. Ты только что вошёл в систему. Сервер тебе в руки пихает:

    • Access Token (JWT): Короткий пропуск. Ты его прикладываешь к каждому запросу (Authorization: Bearer <token>), типа «я свой, впустите».
    • Refresh Token: Длинная случайная строка. Её сервер тупо записывает к себе в базу, привязывая к твоему ID. Ты её получаешь и прячешь.

  2. Твой Access Token протух. Ты не бежишь снова вводить логин-пароль, а просто достаёшь свой Refresh Token и несёшь его на тот самый эндпоинт.

    • Сервер смотрит: «Ага, такой токен у меня в списке живых числится, пользователь такой-то».
    • Сразу же вычёркивает этот Refresh Token из списка. Одноразовый же, ёпта!
    • Генерирует для тебя абсолютно новую парочку — и Access, и Refresh токены.
    • Отдаёт тебе. И пошёл ты с новыми ключами дальше гулять.

Вот как это примерно в коде выглядит (логика сервера):

# Эндпоинт /auth/refresh
def refresh_token_endpoint(refresh_token_from_client):
    # 1. Ищем этот токен в своей базе
    token_record = db.find_refresh_token(refresh_token_from_client)
    if not token_record or token_record.expired:
        return 401, "Invalid refresh token" # Не, чувак, это фуфло, иди нахуй

    # 2. Старый refresh token — в утиль! Больше он не катит.
    db.delete_refresh_token(refresh_token_from_client)

    # 3. Делаем два новых
    user_id = token_record.user_id
    new_access_token = create_jwt(user_id, expires_in='15m')
    new_refresh_token = generate_secure_random_string() # Случайная строка, овердохуища символов
    db.save_refresh_token(user_id, new_refresh_token, expires_in='7d')

    # 4. Отдаём обновку
    return {
        "access_token": new_access_token,
        "refresh_token": new_refresh_token
    }

А зачем вообще этот цирк? Да чтобы не было мучительно больно! Если бы Access Token жил долго, то любой, кто его украл, мог бы годами от твоего имени творить хуйню. А если бы он жил 15 минут и всё, ты бы каждые четверть часа заново логинился — терпения ноль ебать. А так — украли короткий Access Token? Ну и хуй с ним, через 15 минут он мёртв. Украли длинный Refresh Token? А его можно в любой момент отозвать на сервере (удалить из базы), и вор останется с хуем в пальто. Удобно и относительно безопасно.

© ХакСобесов, 2026
support@hacksobesov.com