Чтобы тестировать OAuth-колбэки локально, нужен публичный HTTPS-URL, указывающий на ваше локальное приложение. OAuth-провайдеры после аутентификации перенаправляют пользователя на зарегистрированный URL колбэка — и большинство требует HTTPS, который чистый localhost не обеспечивает без дополнительной настройки.
Почему redirect URI блокируют localhost
Провайдеры OAuth 2.0 проверяют параметр redirect_uri по белому списку зарегистрированных URL. Во время разработки ваш колбэк может выглядеть так:
https://your-app.portpreview.dev/auth/callback
Без туннеля вы либо регистрируете http://localhost:3000/auth/callback (разрешено некоторыми провайдерами, но не всеми), либо деплоите на staging при каждом изменении авторизации. Туннель к localhost даёт настоящий HTTPS-эндпоинт на вашей машине.
Что нужно для локального тестирования OAuth
- Учётные данные OAuth-приложения (client ID и secret) от провайдера.
- Локальное приложение с маршрутами авторизации для запуска логина и обработки колбэка.
- URL туннеля, зарегистрированный как разрешённый redirect URI в панели провайдера.
- Переменные окружения, указывающие на URL туннеля во время разработки.
Пошагово: локальное тестирование OAuth с PortPreview
- Запустите приложение локально с включёнными маршрутами OAuth.
- Выполните
npx portpreview 3000, чтобы получить публичный HTTPS-URL. - Добавьте URL колбэка (например,
https://your-app.portpreview.dev/auth/callback) в список разрешённых redirect URI вашего OAuth-провайдера. - Настройте локальное окружение так, чтобы оно использовало URL туннеля как базовый.
- Запустите OAuth-флоу в браузере и пройдите полный цикл редиректа.
- Проверьте обмен токенами, создание сессии и обработку ошибок.
Советы по провайдерам
Google OAuth
Google разрешает http://localhost для разработки, но тестирование через HTTPS-туннели проверяет поведение, близкое к продакшену, включая флаги secure-cookie и политики смешанного контента.
GitHub OAuth
GitHub требует точного совпадения redirect URI. Зарегистрируйте URL туннеля в настройках OAuth-приложения и обновляйте его при смене сессии туннеля либо используйте стабильный субдомен, если провайдер туннеля это поддерживает.
Auth0 и корпоративные IdP
Корпоративные провайдеры идентификации часто требуют HTTPS-колбэки и иногда полностью запрещают localhost. Туннели — стандартный обходной путь для локального тестирования интеграций SAML и OIDC.
Частые ошибки локального тестирования OAuth
- Несовпадение redirect URI: URL колбэка должен совпадать точно, включая завершающие слеши и регистр пути.
- Устаревший URL туннеля: если URL туннеля меняется между сессиями, обновите белый список провайдера.
- Параметр state не проверяется: всегда проверяйте параметр
stateдля защиты от CSRF, даже в разработке. - Проблемы с доменом cookie: сессионные cookie могут не сохраняться, если настройки домена конфликтуют с хостнеймом туннеля.
Вопросы безопасности
OAuth-колбэки несут коды авторизации, которые должны обмениваться на стороне сервера. Никогда не раскрывайте client secret во фронтенд-коде и считайте URL туннелей временными эндпоинтами разработки, а не продакшен-доменами. Прочитайте наше руководство по безопасности туннелей к localhost для лучших практик.
Делитесь OAuth-флоу с командой
Когда продукт или QA нужно протестировать вход через соцсети, делитесь URL туннеля вместо деплоя на staging. Смотрите как поделиться локальным dev-сервером для совместных воркфлоу.
Присоединяйтесь к листу ожидания PortPreview, чтобы упростить тестирование OAuth и вебхуков из одного туннеля.