Замокать discovery-документ OpenID Connect

GET-мок на /.well-known/openid-configuration с issuer, authorization_endpoint, token_endpoint и jwks_uri.

Клиенты OpenID Connect стартуют с того, что забирают discovery-документ по /.well-known/openid-configuration и читают из него адреса эндпоинтов. Шаблон отдаёт такой документ, так что шаг discovery — и то, как его обрабатывает ваш клиент, — можно проверить, не поднимая провайдера.

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

Тело ответа

{"issuer":"{{mock.url}}","authorization_endpoint":"{{mock.url}}/authorize","token_endpoint":"{{mock.url}}/token","jwks_uri":"{{mock.url}}/.well-known/jwks.json","response_types_supported":["code"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"]}

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

Поле Что означает
issuer URL issuer'а, с которым клиент сравнивает claim iss в токенах; должен точно совпадать с базовым URL.
authorization_endpoint Куда клиент отправляет пользователя для логина.
token_endpoint Где клиент обменивает код на токены.
jwks_uri Где клиент берёт публичные ключи — сочетается с шаблоном jwks-endpoint.

Создать мок

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "GET",
  "response_status": 200,
  "content_type": "application/json",
  "path_suffix": ".well-known/openid-configuration",
  "response_body": "{\"issuer\":\"{{mock.url}}\",\"authorization_endpoint\":\"{{mock.url}}/authorize\",\"token_endpoint\":\"{{mock.url}}/token\",\"jwks_uri\":\"{{mock.url}}/.well-known/jwks.json\",\"response_types_supported\":[\"code\"],\"subject_types_supported\":[\"public\"],\"id_token_signing_alg_values_supported\":[\"RS256\"]}"
}'

Вызвать

curl https://quickmock.dev/m/<slug>/.well-known/openid-configuration

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

GET /m/<slug>/.well-known/openid-configuration -> 200 an OIDC discovery document
every advertised endpoint resolves to this mock via the {{mock.url}} token

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

Все URL в этом документе собраны из токена {{mock.url}}, поэтому на каждый запрос раскрываются в собственный адрес мока — но за самими эндпоинтами ничего не стоит, так что клиент проходит discovery и дальше не идёт. Правка тела ответа требует admin-токена из баннера при создании — подробнее в /guide/manage-mocks-from-any-device.

Источники

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

Нужно ли что-то править перед использованием?
Нет. Каждый URL в документе записан токеном {{mock.url}}, который на каждом запросе раскрывается в собственный адрес мока https://quickmock.dev/m/<slug> — документ согласован сам с собой сразу после создания. Править его нужно только если вы хотите увести эндпоинты куда-то ещё.
Почему issuer обязан совпадать точь-в-точь?
Клиенты сверяют issuer из документа с claim iss в полученных токенах и отклоняют расхождение. Достаточно лишнего слеша, чтобы всё сломалось, — поэтому это стоит протестировать намеренно.
Можно ли пройти на нём настоящий логин?
Нет. Документ объявляет эндпоинты, но ни один из них не реализован. Соедините его с шаблоном токен-ответа OAuth2 для шага обмена и с JWKS-шаблоном для получения ключей, чтобы покрыть больше потока.

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

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

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

Похожие шаблоны

← Все шаблоны

Обновлено: 2026-10-17