Перейти на PRO

Какие виды токенов используются в веб-разработке и API?

Тип вопроса: API тестирование Вероятность: 10% Категория: QA Тестировщик

Ответ

Токены — это цифровые ключи для аутентификации и авторизации. Основные виды:

  1. Access Token — короткоживущий токен (минуты/часы), который клиент предъявляет для доступа к защищенным ресурсам. Часто реализуется как JWT (JSON Web Token).

    // Пример структуры JWT (Header.Payload.Signature)
// Payload (полезная нагрузка):
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622
}

    Передается в заголовке: Authorization: Bearer <token>

  2. Refresh Token — долгоживущий токен (дни/месяцы), используемый для получения нового Access Token'а без повторного ввода учетных данных. Хранится на стороне клиента максимально безопасно (например, в HttpOnly cookie).

  3. Bearer Token — не конкретный вид, а способ использования токена. Указывает, что предъявитель (bearer) токена получает доступ. Именно так передаются Access Token'ы.

  4. CSRF Token (Token-based CSRF Protection) — уникальное, секретное и непредсказуемое значение, генерируемое сервером и передаваемое клиенту (часто в скрытом поле формы). Нужен для защиты от межсайтовой подделки запросов.

    <form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="a1b2c3d4e5f6">
  <!-- другие поля -->
</form>

  5. API Key — статичный идентификатор, используемый для аутентификации вызовов API. Менее безопасен, чем схема с токенами, так как не имеет срока действия и часто передается в URL или заголовках. Пример: https://api.example.com/data?api_key=your_secret_key

Для тестирования важно проверять:

  • Валидацию срока жизни (exp claim в JWT).
  • Обработку HTTP-кодов 401 Unauthorized и 403 Forbidden.
  • Механизм обновления пары Access/Refresh Token.
  • Безопасную передачу (HTTPS) и хранение (не в localStorage для Production).

Ответ 18+ 🔞

А, токены, блядь! Ну, цифровые ключики, которые везде сую́т, чтобы понять — ты свой или левый мудак. Давай разжую, как есть, а то в этих мануалах нихуя не понятно.

Access Token — это типа пропуск на тусовку, но одноразовый, живёт минут пятнадцать, ну, может, час. Его ты суёшь охране (серверу) и проходишь к барам (ресурсам). Часто это JWT, такая хуйня в три части, где в серединке вся инфа о тебе лежит. Смотри, как выглядит:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622
}

exp — это когда он сдохнет, ёпта. И тащить его надо в заголовке: Authorization: Bearer <token>. То есть, типа, «эй, предъявитель этого куска текста — Джонни, впустите его».

Refresh Token — это уже не пропуск, а, блядь, членский билет в этот клуб. Долгоживущий, пиздец как. Его ты хранишь в самом надёжном месте — не в localStorage, а, например, в HttpOnly куке, чтобы никакой фронтенд-скрипт его не стырил. Когда Access Token сдох — ты этим билетом машешь и тебе выдают новый пропуск. Удобно, не надо каждый раз логин-пароль вбивать.

Bearer Token — это не отдельный вид, а способ, сука, использования. Как будто говоришь: «Кто этот токен принёс — тот и прав». Вот Access Token как раз так и передаётся — как Bearer.

CSRF Token — о, это отдельная песня, блядь! Это такая хитрая жопа, чтобы тебя не наебали. Представь: ты залогинился на банке, а тебе на почту приходит письмо «посмотри котиков», ты кликаешь, а там невидимая форма тебе все бабки на Казахстан переводит. Так вот, CSRF токен — это скрытое поле в форме, уникальное для каждой сессии. Сервер его сгенерил и ждёт. Если его нет или он не совпал — запрос нахуй.

<input type="hidden" name="csrf_token" value="a1b2c3d4e5f6">

Без этого значения — никаких переводов, пиздец.

API Key — это вообще старый дедовский способ, как отмычка простая. Постоянный ключ, который ты суёшь в каждый запрос, часто прямо в URL. Типа ?api_key=твой_секретный_ключ. Но он, блядь, опасный! Если его спалят — всё, твой аккаунт как подопытный кролик. У него срока годности нет, отозвать сложно. В общем, для продакшена — так себе идея, честно.

А теперь, блядь, что тестировать надо, чтобы не облажаться:

  1. Срок жизни (exp) — что будет, если токен протух? Должна быть ошибка 401 Unauthorized, а не тихое падение в бездну.
  2. Коды ответов — 401 (ты неизвестный мудак) и 403 (ты известный, но доступ тебе закрыт, пидор) должны чётко отрабатывать.
  3. Обновление пары — работает ли схема «отдал старый Access Token и Refresh Token — получил новую пару»? А что, если Refresh Token тоже протух или его украли?
  4. Безопасность — всё летит по HTTPS? Токены не светятся в логах? Access Token не засунули в localStorage на продакшене (это, блядь, прямой путь к краже сессии)?

Вот так, коротко и по делу, без этих ваших заумных «инфраструктур идентификации». Просто запомни: токен — это не магическая хуйня, а просто строка, которую сервер умеет читать и проверять. А если не умеет — то это пиздец, а не авторизация.

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