Ответ
Access Token (токен доступа) — это учетные данные, выданные клиенту после успешной аутентификации (например, через OAuth 2.0). Он используется для авторизованного доступа к защищенным ресурсам API вместо постоянной передачи логина и пароля.
Основные характеристики:
- Строка (часто в формате JWT — JSON Web Token).
- Имеет ограниченный срок жизни (поле
exp). - Содержит информацию о правах доступа (scopes).
- Передается в заголовке HTTP-запроса:
Authorization: Bearer <token>.
Пример структуры JWT (декодированная полезная нагрузка):
{
"sub": "user123",
"name": "Alice Smith",
"iat": 1516239022,
"exp": 1516242622,
"scope": "read:profile write:settings"
}Типичный поток использования:
- Клиент получает токен, отправив учетные данные на эндпоинт
/oauth/token. - Клиент использует этот токен в запросах к API.
- Сервер ресурсов проверяет валидность и права токена.
Что важно тестировать:
- Истечение срока действия токена (должен возвращаться
401 Unauthorized). - Доступ только в рамках выданных прав (scopes).
- Защиту от перехвата (обязательное использование HTTPS).
- Возможность отзыва токена (revocation).
Ответ 18+ 🔞
О, слушай, а вот этот ваш «Access Token», он же просто кусок строки, который после всей этой пляски с бубном вокруг логина и пароля тебе выдают, типа «держи, браток, теперь ты свой». По сути, это пропуск в закрытый клуб API, чтобы каждый раз не тыкать в систему свои паспортные данные, как последний лох.
Что это за зверь такой, по-простому:
- Просто строка, но часто зашифрованная по всем правилам искусства (этот JWT, там внутри куча всякой инфы).
- Живёт недолго, как мотылёк — у него есть срок годности, поле
exp. Просрочился — и всё, пиздец, доступ закрыт. - Внутри написано, что тебе можно — эти самые
scopes(права). Читать профиль? Писать настройки? Всё расписано. - Таскают его в заголовке запроса, как флаг:
Authorization: Bearer <token>. Без этого — нихуя не получишь.
Вот, смотри, как эта хрень внутри выглядит, если её распаковать:
{
"sub": "user123",
"name": "Alice Smith",
"iat": 1516239022,
"exp": 1516242622,
"scope": "read:profile write:settings"
}Видишь? Кто (sub), когда выпущен (iat), когда сдохнет (exp) и что можно делать (scope). Всё прозрачно, блядь.
Как этим пользоваться, чтобы не облажаться:
- Получаешь ключ от квартиры. Шлёшь свои креды на специальную дверь
/oauth/token. Тебе в ответ — токен, ёпта! - Машешь этим ключом перед носом у API. Вставляешь его в каждый запрос к защищённым ресурсам.
- А система, хитрая жопа, проверяет: а не поддельный ли ключ? а не просрочен ли? а можно ли этому челу то, что он просит?
И вот на чём надо мозги ебать, когда тестируешь эту механику:
- Сроки, сука, сроки! Что будет, когда токен откинется? Должна быть ошибка
401 Unauthorized, а не тихое падение в бездну или, того хуже, доступ к чужим данным. Это раз. - Права доступа. Выдал права только на чтение (
read:profile) — а он вдруг начинает писать (write:settings). Система должна послать его нахуй с403 Forbidden. Это два. - HTTPS или смерть. Если это болтается по открытому каналу — это пиздец. Токен перехватят и будут творить, что хотят, от твоего имени. Обязательно проверь, что всё летает только по защищённому соединению. Это три.
- А можно ли его досрочно прибить? Отзыв токена (revocation) — важная фича. Пользователь вышел из системы, заподозрили хуйню — токен должен мгновенно стать куском бесполезного текста. Проверь, работает ли этот механизм. Это четыре, блядь.
Вот и вся магия. Не так страшен чёрт, как его малюют, но и расслабляться нельзя — тут каждая мелочь может стать дырой размером с амбарную дверь.