После обновления не входит в аккаунт: что проверить сначала
Зафиксируйте точное время сбоя, версию релиза, HTTP-код и текст первой ошибки. Затем проверьте health check приложения, reverse proxy и IdP, соберите журналы за период до и после релиза, сравните версии и конфигурацию. Совпадение ошибки со временем обновления указывает на гипотезу, но не подтверждает причину без логов и сравнения изменений.
Не удаляйте все cookie, сессии и локальные учетные данные до сохранения диагностической информации. Такое действие иногда возвращает вход одному пользователю, но уничтожает следы проблемы. Начните с тестовой учетной записи, меняйте один параметр за раз и сохраняйте рабочую конфигурацию перед любым исправлением.
- Запишите время релиза в UTC, номер сборки, версии ОС, приложения, auth-библиотеки, proxy и IdP-коннектора.
- Определите масштаб: не входит один пользователь, отдельный тип клиента, сегмент сети или все пользователи.
- Проверьте статус сервиса, IdP, DNS, сертификатной цепочки и доступность endpoint для token exchange.
- Соберите логи приложения, reverse proxy, IdP, оркестратора и клиента по одному correlation ID или временному интервалу.
- Сравните текущую конфигурацию с резервной копией и предыдущей версией. При массовом сбое и готовом плане возврата подготовьте rollback.
Сначала сохраните факты: время, версии, HTTP-коды, request ID и конфигурационный diff. Затем устраняйте подтвержденную причину.
Определите, где именно ломается цепочка входа
Цепочка входа обычно выглядит так: клиент или CLI/IDE, сеть и proxy, приложение или reverse proxy, IdP, redirect или token exchange, создание сессии, проверка authorization. Ошибка на каждом этапе требует разных действий. Разделите невозможность отправить запрос, отказ IdP, сбой обмена токеном, потерю сессии и отказ в доступе по роли.
| Этап | Наблюдаемый признак | Где проверять |
|---|---|---|
| Клиент | Запрос не появился в сетевом журнале | Версия приложения, время системы, credential store, cookie, proxy |
| Сеть и proxy | Timeout, TLS-ошибка, 502 или обрыв redirect | DNS, маршрут, журналы reverse proxy, сертификаты |
| IdP | Отказ после перенаправления на страницу входа | Логи IdP, MFA, политики, client ID, redirect URI |
| Token exchange | Ошибка invalid_grant, invalid_client или отказ callback | Параметры OAuth 2.0, OIDC или SAML, секрет, время, код авторизации |
| Сессия | Вход успешен, затем приложение снова просит войти | Set-Cookie, Cookie, session store, trusted proxy |
| Authorization | Пользователь распознан, но ресурс недоступен | Claims, scopes, группы, роли, правила доступа |
Ошибка возникает до отправки запроса
Проверьте вход той же учетной записью в другом браузере, desktop-клиенте, CLI и IDE. Если браузер работает, а CLI получает локальную ошибку, проблема часто находится в профиле клиента, системном хранилище учетных данных, переменных proxy или устаревшей библиотеке.
Сверьте версию клиента с матрицей совместимости сервиса. После обновления ОС могут измениться системные корневые сертификаты, TLS-библиотека, политика хранения cookie или версия встроенного браузера. Проверьте системное время до очистки cache:
date -u
timedatectl status
getent hosts "$IDP_HOST"Сохраните журнал клиента и сведения о выбранном профиле. Проверьте переменные HTTPS_PROXY, HTTP_PROXY и NO_PROXY, адрес целевого host, локальные сертификаты и способ хранения credentials. Не удаляйте credential store на рабочем устройстве, пока не воспроизведете сбой на тестовом клиенте.
Запрос доходит до сервиса, но возвращается 401 или 403
Код 401 обычно означает, что сервис не получил учетные данные или не принял их: токен истек, подпись не прошла проверку, issuer или audience не совпали. Код 403 означает, что сервис распознал пользователя, но запретил действие из-за роли, scope, группы, политики или ограничений по IP.
Не исправляйте 403 сменой пароля или массовым сбросом сессий. Сначала сравните claims успешного и неуспешного пользователя, требуемые scopes, членство в группах и правила authorization. Коды 400 часто указывают на некорректный callback или параметры token exchange, а 502 требует проверки связи proxy с upstream-сервисом.
Сбой появляется на redirect, token exchange или при подключении
Сверьте redirect URI посимвольно: схему, host, порт, path и завершающий слеш. Адрес в конфигурации приложения должен совпадать с адресом, зарегистрированным у IdP. Подмена https на http за reverse proxy, другой порт или старый callback после миграции дают отказ еще до создания сессии.
Проверьте issuer, DNS, сертификатную цепочку, доступность endpoint IdP и настройки proxy. При TLS-сбое полезно проверить, какой сертификат видит клиент:
openssl s_client -connect "$IDP_HOST:443" -servername "$IDP_HOST" </dev/nullОбрыв соединения не доказывает ошибку учетной записи. Его могут вызвать DNS, сетевой фильтр, неверный маршрут, timeout или proxy. Для проверки пути запроса используйте приемы из статьи о диагностике маршрутизации в веб-приложениях и микросервисах.
Сверьте версии клиента, сервиса и зависимостей
Зафиксируйте связку компонентов, а не один номер релиза. Обновленный сервер может требовать новые параметры OIDC, а новый клиент может отправлять cookie или заголовки в формате, который старый proxy обрабатывает неверно. Build number, образ контейнера и версия библиотеки иногда точнее обозначают проблему, чем версия продукта.
| Компонент | Что записать | Что сравнить |
|---|---|---|
| Операционная система | Релиз, ядро, пакеты TLS и CA | Системные сертификаты, криптополитики, время |
| Клиент | Версия, build, тип клиента | Поддерживаемый браузер, CLI, IDE, API-версия |
| Сервер приложения | Образ, commit, runtime | Breaking changes, обработка токенов и сессий |
| Auth-библиотека | Версия пакета и настройки | Алгоритмы подписи, JWKS, issuer, audience |
| Reverse proxy | Версия и полный config | Заголовки forwarding, TLS, cookie, upstream |
| IdP-коннектор | Версия и режим интеграции | OAuth 2.0, OIDC, SAML, MFA и политики |
Сравните поддерживаемую комбинацию компонентов
Проверьте release notes и матрицу совместимости для связки клиент, сервер, библиотека и IdP. Ищите изменения формата API, минимальной версии браузера, допустимых алгоритмов JWT, схемы cookie, требований к TLS, формата claims и поведения refresh token.
Проверьте, не обновился ли один компонент цепочки. Типичный сценарий: сервер начинает ожидать новый issuer или audience, IdP продолжает выдавать старое значение, а ошибка выглядит как обычный отказ во входе. Второй сценарий: обновление auth-библиотеки перестает принимать устаревший алгоритм подписи или сертификат без полной цепочки доверия.
Проверьте отдельные клиенты и интеграции
Используйте одну учетную запись на нескольких клиентах: браузер, desktop-приложение, CLI, IDE и API-клиент. Сравнение дает быстрый результат:
- работает только браузер - проверьте профиль CLI, token cache, proxy и версию SDK;
- работает только старый клиент - проверьте совместимость нового клиента, callback и формат токена;
- не работает за одним proxy - проверьте DNS, TLS, заголовки и trusted proxy;
- вход проходит, но API возвращает
403- проверьте scope, роль и policy engine.
Убедитесь, что каждый клиент использует ожидаемый host и профиль. После обновления часть приложений может остаться привязанной к старому endpoint, системному proxy или сохраненному набору credentials.
Сравните конфигурацию до и после обновления
Сравните конфигурацию из системы контроля версий, переменные окружения, ссылки на секреты, смонтированные файлы, параметры запуска и настройки инфраструктуры. Секреты не выводите в diff и не отправляйте в журналы. Сравнивайте имена секретов, версии ссылок, права процесса и наличие файлов.
| Параметр | Типичный симптом | Проверка |
|---|---|---|
| Endpoint IdP и issuer | invalid issuer, redirect на другой host | Значения в приложении, discovery и IdP |
| Client ID и secret reference | invalid_client | Имя переменной, доступ процесса, версия секрета |
| Redirect URI | redirect_uri mismatch | Схема, host, порт, path, завершающий слеш |
| Cookie domain и SameSite | Циклический вход после callback | Set-Cookie и следующий запрос браузера |
| Trusted proxy и allowed hosts | Неверный внешний URL или отказ redirect | Forwarded-заголовки и список доверенных proxy |
| TLS и сертификаты | certificate verify failed | Срок, цепочка, SAN, доверенные CA |
Проверьте секреты, сертификаты и redirect URI
Пакет при обновлении может переименовать переменную окружения, изменить путь к secret storage или запустить сервис от другого UID. Убедитесь, что процесс читает нужный secret и имеет права на файл или volume. Проверьте, что сертификат не истек, содержит нужный SAN и передается с полной цепочкой.
Redirect URI сверяйте посимвольно на трех сторонах: в приложении, в reverse proxy и в настройках IdP. Учитывайте внешний адрес, который видит пользователь. Внутренний адрес контейнера не должен попадать в callback, если вход идет через публичный proxy.
Проверьте системное время и новые политики безопасности
JWT, authorization code и SAML assertion чувствительны к времени. Ошибка clock skew появляется, когда часы клиента, сервера и IdP расходятся сильнее допустимого окна. Сверьте UTC на всех узлах и состояние синхронизации NTP. Не меняйте время вручную на одном сервере без проверки источника синхронизации.
Сравните новые требования к MFA, TLS, алгоритмам подписи, сроку жизни токенов, session timeout, trusted origins, cookie SameSite и Secure. Политика может применяться к новым запросам и сессиям, поэтому старый сеанс иногда продолжает работать, а новый вход получает отказ. Для случаев, где ошибка зависит от пользователя, устройства или сети, используйте чек-лист по проверке MFA, SSO и политик доступа.
Посмотрите журналы сразу после релиза
Соберите логи приложения, reverse proxy, IdP, auth-библиотеки, клиента и оркестратора за один временной интервал. Связывайте события по времени, hostname, user ID в безопасном виде, request ID и correlation ID. Полный access token, refresh token, пароль, client secret и authorization code в журнал не записывайте.
Найдите первый отказ в цепочке, а не последнюю строку с ошибкой. Proxy может показать 502, хотя первопричина находится в upstream-сервисе, который не смог проверить подпись JWT. Подробный порядок сбора и чтения событий приведен в статье как читать логи при ошибке аутентификации.
Разберите типовые сообщения об ошибках
| Сообщение | Вероятная причина | Следующая проверка |
|---|---|---|
invalid issuer | Не совпадает issuer токена и ожидаемое значение | Endpoint IdP, discovery, конфигурация сервиса |
invalid audience | Токен выпущен для другого клиента или API | Client ID, audience, resource server |
invalid signature | Неверный ключ, алгоритм или устаревший JWKS | Ключи подписи, cache, допустимые алгоритмы |
expired token | Истек exp или расходится время | UTC, NTP, TTL и refresh flow |
invalid grant | Code уже использован, истек или callback не совпал | Redirect URI, время, повторное использование code |
cookie rejected | Браузер не сохраняет cookie | Domain, Path, SameSite, Secure, HTTPS |
certificate verify failed | Недоверенный, просроченный или неполный сертификат | Цепочка, CA store, SAN, время |
session store unavailable | Backend не читает или не сохраняет сессию | Доступность хранилища, сетевые правила, ключ подписи |
Сравните логи до и после изменения
Возьмите один успешный вход до релиза и один неуспешный после него. Сравните endpoint, HTTP-коды, порядок redirect, длительность запросов, issuer, audience, тип grant, наличие callback и предупреждения библиотеки. Скрывайте заголовок Authorization, cookie и другие секретные значения.
14:02:11 deploy completed, build=2026.08.31
14:03:07 auth callback, status=302, request_id=abc123
14:03:08 token exchange, status=400, error=invalid_grant
14:03:08 login failed, request_id=abc123Такая цепочка сужает поиск до token exchange. Если перед ошибкой нет callback, проверьте redirect, DNS, сертификаты и доступность IdP. Если callback есть, а сессия сразу теряется, проверьте cookie и session store.
Проверьте токены, сессии и формат авторизации
После обновления IdP может выдавать токен с новыми claims, сервис может ожидать другой audience или библиотека может запретить прежний алгоритм подписи. Пользователь в такой ситуации часто успешно проходит ввод пароля и MFA, но приложение отклоняет результат.
Показывайте в диагностике только безопасные поля: issuer, audience, subject, scopes, срок действия и идентификатор ключа. Полные JWT, refresh token, session cookie, authorization code и client secret нельзя публиковать в тикетах, чатах или открытом diff.
Проверьте JWT и параметры обмена токеном
Сверьте iss, aud, sub, scope, роли, exp, nbf, алгоритм подписи и ключ. Декодирование JWT помогает увидеть payload, но не подтверждает подлинность токена. Подпись сервис должен проверить по доверенному ключу и разрешенному алгоритму.
Для token exchange проверьте endpoint, grant type, redirect URI, client authentication и время жизни authorization code. Code обычно одноразовый: повторная отправка после retry часто дает invalid_grant. Отдельно проверьте refresh token. Его формат, срок жизни, ротация и scope могут измениться после обновления IdP или auth-библиотеки.
Проверьте cookie и серверную сессию
Проверьте ответ Set-Cookie после callback и следующий запрос браузера с заголовком Cookie. Домен и path должны покрывать нужный адрес, Secure требует HTTPS, а SameSite влияет на возврат с внешнего IdP. При TLS-терминации на proxy приложение должно корректно видеть внешний HTTPS-протокол через доверенные forwarded-заголовки.
Проверьте доступность общего session store для всех реплик приложения, ключ подписи cookie и формат сериализации сессий. Во время поэтапного выката разные версии приложения могут по-разному читать одну сессию. Очистите cookie только на тестовом клиенте после сохранения HAR или сетевого лога и подтверждения воспроизводимости.
Выберите: исправлять конфигурацию или выполнять rollback
Исправляйте конфигурацию, когда журналы подтверждают один конкретный параметр: неверный redirect URI, недоступный secret, истекший сертификат, неправильный issuer или ошибка trusted proxy. Вносите одно изменение, повторяйте тест и фиксируйте результат.
Rollback нужен при массовом отказе, явной связи с новым релизом, наличии совместимой предыдущей версии и проверенного плана возврата. Используйте предыдущий образ, blue-green deployment или feature flag, если такие механизмы подготовлены. Учтите миграции базы, ротацию секретов, изменения формата сессий и уже выданные токены.
Что сохранить до отката
- временные рамки сбоя, correlation ID и журналы всех компонентов;
- release manifest, тег предыдущего образа, hash сборки и состояние health check;
- diff конфигурации, ссылки на секреты, параметры запуска и mounted files;
- состояние миграций, схему session store и сведения о ротации ключей;
- резервную конфигурацию и результат теста на предыдущей версии.
Не удаляйте старые образы и не перезаписывайте журналы во время возврата. При обновлении reverse proxy сохраните полный config и проверку синтаксиса. Практический сценарий резервного копирования и быстрого восстановления описан в чек-листе обновления Nginx.
Тестовый контур полезно держать изолированным от production-учетных данных и боевых секретов. Для временного стенда, где можно проверить предыдущий образ, обратимость миграций и auth smoke test, подойдет облачная инфраструктура Timeweb Cloud.
Как проверить результат восстановления
Проверяйте результат по сценариям, а не по одной успешной загрузке страницы. Сравните показатели ошибок с baseline до обновления и наблюдайте сервис после исправления или rollback.
| Проверка | Ожидаемый результат |
|---|---|
| Вход тестового пользователя | Успешный callback и создание новой сессии |
| Пользователь с существующей сессией | Предсказуемая работа или контролируемое переоформление сессии |
| Logout | Cookie и серверная сессия инвалидируются |
| Refresh token | Новый access token выдается без ошибки grant |
| MFA | Второй фактор проходит, policy применяется ожидаемо |
| Защищенный ресурс | Разрешенная роль получает доступ, запрещенная получает 403 |
| CLI, API и путь через proxy | Каждый штатный клиент проходит свой сценарий входа |
Добавьте контрольные проверки в следующий релиз
Соберите короткий auth smoke test для staging и production: login, redirect, callback, token exchange, refresh, logout, MFA, проверка роли и истечение сессии. Закрепите поддерживаемые версии, обязательные параметры конфигурации, владельцев секретов, условия rollback и ссылку на runbook в release checklist.
Проверки перед обновлением
- Сохраните резервную конфигурацию, предыдущий образ и текущие метрики
401,403, TLS-ошибок и ошибок token exchange. - Проверьте матрицу совместимости клиента, сервера, auth-библиотеки, reverse proxy и IdP-коннектора.
- Запустите smoke test на staging с тестовыми учетными записями, MFA и минимально привилегированной ролью.
- Сверьте redirect URI, issuer, audience, secret references, сертификаты, DNS и системное время.
- Убедитесь, что миграции обратимы или описан порядок возврата после необратимого изменения.
Проверки после обновления
Проверьте auth smoke test сразу после релиза, затем повторите его через 15 и 60 минут. Просмотрите status сервисов, журналы IdP и reverse proxy, долю 401 и 403, ошибки TLS, длительность callback и token exchange. Настройте алерт на резкий рост отказов относительно baseline, а в change log фиксируйте измененные политики, версии библиотек и параметры сессий.
Такой порядок оставляет воспроизводимые доказательства, сокращает время локализации и дает контролируемый путь к исправлению или возврату рабочей версии.