1. Установите роли и этап отказа
Зафиксируйте реальный релиз, realm, client и UTC-интервал. Установите, что Keycloak делает в этой связи: обслуживает приложение как OpenID Provider или обращается к внешнему IdP как брокер. Данная ветка разбирает приложение → authorization endpoint → token endpoint. Сохраните последнее подтверждённое действие и имя наблюдающей системы. Ответ браузера, журнал приложения и server user event изучаются как отдельные свидетельства. Не объединяйте их лишь по соседству времени; общий прокси-адрес и название клиента не задают уникальную попытку.
2. Различите три класса ошибок
Для invalid_redirect_uri сначала исследуйте authorization endpoint: в 26.8.1 checkRedirectUri записывает ошибку события и отклоняет неподходящий URI. invalid_client в ответе token endpoint означает отказ аутентификации клиента, например из-за неизвестного клиента или неподходящего метода. invalid_grant относится к grant/refresh token: возможны истечение, отзыв, иное redirect URI или принадлежность другому клиенту. Это не три синонима неверного пользовательского пароля. Укажите endpoint, grant_type и точный слой error до выбора дальнейшей ветки.
3. Проверьте redirect без изменения настроек
Сопоставьте URI из разрешённой копии запроса с зарегистрированными адресами клиента: схема, хост, порт, путь, регистр и фактические значения должны рассматриваться вместе с настройками proxy/hostname. На этом шаге фиксируется расхождение, а не добавляется широкая маска. Ошибка redirect может произойти до установленного пользователя. При невалидном redirect URI стандарт OIDC не допускает перенаправление браузера на него, поэтому отсутствие callback в приложении не означает пропажу серверного события. Исправление конфигурации и проверочный вход являются отдельной операцией владельца интеграции.
4. Прочитайте два независимых примера
LOGIN_ERROR в примере содержит клиент portal-demo и invalid_redirect_uri. Значение details.redirect_uri относится к проверяемой ветви authorization, а не к успешной выдаче токена. Второй пример — отдельное JSON-тело invalid_grant: оно не утверждает ни конкретный grant_type, ни последовательность с первым событием. Первое jq-выражение читает массив сохранённых Keycloak events; второе читает только JSON-тело OAuth-ответа. Не подавайте им HAR целиком или текстовый server log. Они предназначены для проверки уже полученной обезличенной копии и не отправляют запросов. Приведённые jq-фильтры сами не ограничивают время: используйте массив, заранее выгруженный за нужное UTC-окно, либо добавьте явное условие по time, учитывая миллисекунды Unix-времени. Не смешивайте записи разных периодов только из-за одинаковых realm и клиента.
5. Соберите подтверждения со стороны приложения
Для token endpoint сопоставьте тип клиента, выбранный способ аутентификации, realm и идентификатор клиента по разрешённым метаданным конфигурации. Для invalid_grant проверьте тип обмена, хронологию получения/использования grant, совпадение клиента и redirect URI; сохраните факт повторной обработки в журнале приложения, если он доступен. Не воспроизводите обмен сохранённым кодом и не включайте секреты в отчёт. Достоверный итог может ограничиться этапом и перечнем ещё не проверенных условий. Сообщение браузера само по себе не устанавливает, дошёл ли запрос до token endpoint.
6. Свяжите события, не подменяя identity
Сравните доступные realm/client, время, server event ID и контекст приложения; userId/sessionId используйте только при наличии и после проверки области. CODE_TO_TOKEN_ERROR и LOGIN_ERROR — разные типы; состав и сохранение зависят от конфигурации. Если Keycloak использует LDAP-федерацию, переход к LDAP 49 оправдан только фактическим сообщением LDAP-провайдера. Для изменения клиента или роли ищите admin events отдельно. Привязка к Windows 4625/Kerberos также требует доказанной интеграционной связи, а не предположения по одному и тому же имени пользователя.
7. Если данных недостаточно
Проверьте типы событий, Save events, срок хранения, нужный realm, страницы экспорта и путь доставки. Действующие настройки не доказывают историческую регистрацию. Отсутствие userId на раннем отказе является допустимым состоянием данных; ошибку чтения или доступа нельзя считать пустым журналом. Зафиксируйте отдельно, что отсутствует: HTTP-ответ нужного endpoint, событие Keycloak либо журнал приложения. Не меняйте проверки TLS/redirect/подписи ради диагностики. Сохранённый вывод о месте разрыва полезен даже тогда, когда первопричина требует сведений владельца клиента.