OAuth ломается не в логине, а в мелочах: 5 проверок перед запуском
OAuth — это не «подключил кнопку входа и забыл». Самые дорогие ошибки обычно сидят в стыке redirect URI, state, scopes и хранения токена. Если один из этих слоёв сделан неаккуратно, auth начинает вести себя как случайный баг: то редирект не совпал, то пользователь «успешно вошёл», но сессию не видно.
• Redirect URI должен совпадать символ в символ с тем, что ждёт провайдер и ваш backend. Любая лишняя слэш-деталь ломает флоу.
• Параметр state обязателен: он защищает от подмены ответа и случайных повторов.
• Scopes запрашивайте минимальные: чем шире доступ, тем больше проблем с ревоками и поддержкой.
• Токены не хранят в localStorage без понимания рисков; для чувствительных сценариев лучше опираться на серверную сессию и httpOnly-cookie.
• Обмен code на token делайте на backend, а не в браузере, если нужен контроль над секретами и логикой доступа.
В Supabase это особенно заметно: auth выглядит просто, но реальная надёжность появляется только когда вы отдельно проверили callback-цепочку, правила RLS и то, как сессия живёт между страницами и устройствами.
Если хотите стабильный OAuth, тестируйте не «успешный вход», а весь маршрут: старт, редирект, callback, выдачу сессии, выход и повторный вход.
MID Trust Buyer — MID / chargebacks / PSP
@mid_trust_buyer
OAuth ломается не в логине, а в мелочах: 5 проверок перед запуском
Этот пост опубликован в Telegram-канале MID Trust Buyer — MID / chargebacks / PSP. Подписаться можно по ссылке: @mid_trust_buyer.