Замокать 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