Токены — это настоящие JWT?

Нет: access_token и refresh_token — свежие UUID, а не подписанные JWT. Если ваш клиент декодирует access-токен и читает из него claims, этого шаблона ему не хватит — берите связку с JWKS-шаблоном и настоящим подписанным токеном.

Проверяет ли он grant и учётные данные клиента?

Нет. Он никогда не сверяет client_id, client_secret и код авторизации и всегда возвращает один и тот же успешный ответ. Чтобы протестировать ветку ошибки, заведите второй мок с 400 и телом ошибки OAuth2.

Как протестировать протухание и обновление токена?

Уменьшите expires_in до нескольких секунд, чтобы логика обновления сработала быстро. Поскольку на каждом вызове приходит новый refresh_token, заодно проверяется, что код хранит последний, а не переиспользует первый.

Замокать ответ токена OAuth2

POST-мок, который отдаёт ответ токена в формате RFC 6749 со свежими access_token и refresh_token.

Шаблон отдаёт токен-ответ в форме RFC 6749 — access_token, token_type, expires_in, refresh_token и scope — со свежими значениями токенов на каждом вызове. Он позволяет собрать клиентскую половину OAuth2-потока до того, как появится провайдер, и проверить, что ваш код правильно хранит, обновляет и протухает токены.

Заменяет собой эндпоинт стороннего API.

Тело ответа

{
  "access_token": "{{faker.uuid}}",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "{{faker.uuid}}",
  "scope": "read write"
}

Поля, на которые стоит обратить внимание

Поле	Что означает
access_token	Свежий UUID при каждом вызове через {{faker.uuid}} — не настоящий подписанный токен.
token_type	Захардкожено как Bearer.
expires_in	Захардкоженный срок жизни в секундах; поправьте, чтобы проверить обработку истечения.
refresh_token	Свежий UUID через {{faker.uuid}}.
scope	Строка выданных прав через пробел; поправьте, чтобы проверить логику на основе scope.

Создать мок

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "POST",
  "response_status": 200,
  "content_type": "application/json",
  "response_body": "{\"access_token\":\"{{faker.uuid}}\",\"token_type\":\"Bearer\",\"expires_in\":3600,\"refresh_token\":\"{{faker.uuid}}\",\"scope\":\"read write\"}"
}'

Вызвать

curl -X POST https://quickmock.dev/m/<slug>

Что вы получите

POST /m/<slug> -> 200 an RFC 6749-shaped token response
access_token/refresh_token are fresh UUIDs each call

Чем это отличается от настоящего

access_token и refresh_token — это просто свежие UUID, а не настоящие подписанные JWT; мок не проверяет client_id, client_secret или код авторизации — он всегда отдаёт один и тот же успешный ответ.

Источники

Частые вопросы

Токены — это настоящие JWT?: Нет: access_token и refresh_token — свежие UUID, а не подписанные JWT. Если ваш клиент декодирует access-токен и читает из него claims, этого шаблона ему не хватит — берите связку с JWKS-шаблоном и настоящим подписанным токеном.
Проверяет ли он grant и учётные данные клиента?: Нет. Он никогда не сверяет client_id, client_secret и код авторизации и всегда возвращает один и тот же успешный ответ. Чтобы протестировать ветку ошибки, заведите второй мок с 400 и телом ошибки OAuth2.
Как протестировать протухание и обновление токена?: Уменьшите expires_in до нескольких секунд, чтобы логика обновления сработала быстро. Поскольку на каждом вызове приходит новый refresh_token, заодно проверяется, что код хранит последний, а не переиспользует первый.

Готовы попробовать?

Открыть в конструкторе моков и сначала поправить

Хорошо сочетается с гайдом: Замокать REST API эндпоинт