Если OAuth callback теряет параметры, пользователь успешно подтверждает вход у провайдера, но возвращается не на нужную страницу, получает ошибку state mismatch или приложение не понимает, к какой организации относился запрос. Произвольные query-параметры redirect URI не всегда сохраняются провайдером так, как ожидает приложение.

Контекст авторизации следует передавать через защищенный state и серверное хранилище, а не добавлять return_url, роль или ID организации в callback без проверки. Иначе исправление потери параметров может создать open redirect или подмену аккаунта.

Зафиксируйте всю цепочку перенаправлений

Сравните исходный запрос входа, URL провайдера и фактический callback без автоматического скрытия redirect.

  • В callback есть code, но отсутствует пользовательский return_url.
  • Параметр state не совпадает с сохраненным значением.
  • После входа пользователь всегда попадает на главную.
  • Ошибка проявляется только между разными поддоменами или в iframe.

Почему возникает проблема

OAuth-провайдер возвращает стандартные параметры, а дополнительный контекст должно безопасно хранить приложение.

  • Return URL добавлен в redirect URI, который нормализуется или проверяется провайдером.
  • State перезаписывается параллельной попыткой входа.
  • Сессионная cookie не приходит на callback из-за Domain или SameSite.
  • Reverse proxy меняет схему, host или путь callback.
  • Код декодирует state дважды либо обрезает длинное значение.

Пошаговая диагностика

Используйте одну тестовую попытку с correlation ID и не записывайте authorization code в открытый журнал.

  1. Сохраните redirect URI и state перед отправкой к провайдеру.
  2. Сравните callback с зарегистрированным точным адресом.
  3. Проверьте cookie сессии, host, path, Secure и SameSite.
  4. Проследите redirect через proxy до конечного приложения.
  5. Проверьте обмен code на token и однократное использование state.

Храните контекст на сервере

State должен связывать callback с конкретной попыткой входа и не раскрывать доверенные действия клиенту.

  • Генерируйте криптографически случайный одноразовый state.
  • Связывайте его с return path, PKCE verifier и сроком действия.
  • Разрешайте только внутренние адреса возврата.
  • Удаляйте запись state после успешной или окончательно неуспешной попытки.

Как исправить проблему

Исправляйте схему хранения контекста и cookie, не ослабляя проверку state.

  1. Перенесите дополнительные параметры в серверную запись по state.
  2. Исправьте точный redirect URI у провайдера и в приложении.
  3. Настройте cookie для callback-домена и HTTPS.
  4. Поддержите несколько параллельных попыток входа без перезаписи.
  5. Добавьте PKCE там, где его требует используемый поток.

Как проверить результат

  • Callback принимает только созданный приложением state.
  • Пользователь возвращается на разрешенную исходную страницу.
  • Повторное использование callback отклоняется.
  • Параллельные вкладки не ломают друг другу авторизацию.

Типичные ошибки

  • Отключить проверку state ради успешного входа.
  • Доверять произвольному return_url из callback.
  • Логировать code, token или полный state.
  • Использовать один state для всех пользователей.

Как предотвратить повторение

  • Тестируйте OAuth через разные браузеры и поддомены.
  • Ограничивайте срок жизни и повторное использование state.
  • Храните redirect URI в одной конфигурации.
  • Мониторьте state mismatch без записи секретов.

Когда нужна помощь

Если OAuth callback теряет параметры или адрес возврата, я проверю redirect chain, state, PKCE, cookies и proxy, исправлю поток без отключения защитных проверок.