Что такое OAuth 2.0

OAuth 2.0 нужен, когда одно приложение хочет действовать с ограниченными правами от имени пользователя или получить доступ к его данным в другом сервисе. На интервью важно сказать это просто. Приложение не просит пароль от Google, GitHub или другого сервиса. Оно перенаправляет пользователя к серверу авторизации, получает разрешение и потом работает с токеном.

Например, пользователь нажимает кнопку подключить Google Calendar. Ваше приложение просит доступ только к календарю, получает access token со scope для календаря и отправляет этот токен в API Google. Если токен украден, злоумышленник не получает пароль пользователя. Но он может делать все, что разрешено этим токеном. Поэтому scopes, срок жизни и хранение токена важны для фронтенда.

В ответе достаточно назвать роли простыми словами. Resource owner это пользователь, который владеет данными. Client это приложение, которое просит доступ. Authorization server показывает экран согласия, проверяет пользователя и выдает токены. Resource server это API, которое принимает access token и отдает защищенные данные.

Не говорите так, будто токен выдает сам frontend. Frontend только запускает flow, обрабатывает redirect и отправляет запросы по контракту. Проверять токен, scopes, audience и подпись должен соответствующий сервер или провайдер. Иначе приложение начнет доверять данным, которые не должно проверять само.

Хороший короткий ответ можно построить так:

OAuth 2.0 это протокол авторизации для делегированного доступа. Пользователь разрешает приложению доступ к конкретным ресурсам, а приложение получает access token с ограниченными правами. В браузерных приложениях важно не хранить секреты на фронтенде, использовать Authorization Code Flow с PKCE и защищать redirect через state.

Такая формулировка показывает три уровня: назначение протокола, базовый механизм и практический риск. Если вас спрашивают про кнопку входа через Google, добавьте: для логина обычно используется OpenID Connect поверх OAuth 2.0, потому что нужен факт аутентификации и данные о пользователе.

В современном frontend-ответе важно упомянуть Authorization Code Flow с PKCE. Без PKCE перехваченный authorization code можно обменять на токен. PKCE добавляет одноразовую проверку. Приложение заранее создает code_verifier, отправляет производный code_challenge, а при обмене кода доказывает, что именно оно начало flow.

Упрощенно flow выглядит так:

1. SPA генерирует state и code_verifier.
2. SPA отправляет пользователя на authorization server с code_challenge.
3. Пользователь подтверждает доступ.
4. Authorization server возвращает authorization code на redirect_uri.
5. SPA проверяет state и обменивает code плюс code_verifier на tokens.
6. SPA вызывает API с access token или работает через BFF.

Практический вывод: нельзя просто взять самый короткий flow. Нужно понимать, где токен появляется, кто может увидеть URL, кто хранит секреты и что произойдет при XSS.

Частая ловушка: фраза OAuth 2.0 нужен для аутентификации. В быту так иногда говорят, потому что пользователь нажимает кнопку входа через GitHub. Но в строгом ответе OAuth 2.0 дает приложению право доступа к ресурсу. Он не доказывает личность пользователя для вашего приложения.

Если вам нужно сказать, кто пользователь, нужен OpenID Connect. Он добавляет ID token и стандартный способ получить claims о пользователе. Это полезная деталь в ответе, потому что она показывает, что вы не смешиваете access token для API и данные для логина.

Плохой пример для SPA: положить токен в URL или считать, что env-переменная скрывает секрет клиента.

// Плохо: это попадет в клиентский bundle и не будет секретом.
const clientSecret = import.meta.env.VITE_OAUTH_CLIENT_SECRET;

Переменные с префиксом для клиентской сборки попадают в код, который пользователь может скачать и прочитать. Если провайдер требует client_secret, обмен должен происходить на сервере. Для чистой SPA используйте публичного клиента и PKCE, а не имитацию секрета.

Еще один практический момент: после возврата на redirect_uri не продолжайте flow, пока не проверили state. Иначе можно принять ответ, который не относится к текущей попытке авторизации.

В React-странице redirect не запускайте обмен кода на каждом рендере. authorization code обычно одноразовый, поэтому дубль запроса может дать invalid_grant и перевести уже вошедшего пользователя в ошибку. Безопаснее держать состояние loading, блокировать повторный старт, обрабатывать error, игнорировать результат после unmount и убирать code из URL через replace-навигацию.

В ответе не стоит давать универсальное правило хранить токены в localStorage или хранить только в cookie. Лучше сказать, что выбор зависит от архитектуры и модели угроз.

Если токен доступен JavaScript, XSS может его прочитать. Если доступ к API сделан через httpOnly cookie, JavaScript не прочитает токен напрямую, но нужно защищаться от CSRF, правильно настроить SameSite и CORS. В BFF-подходе токены остаются на сервере, а браузер работает с сессией. Это часто проще контролировать в продукте, где безопасность важнее простоты чистой SPA.

Access token обычно делают короткоживущим. Refresh token, если он попадает в браузер, требует еще более строгой защиты: rotation, ограничение срока, обработка повторного использования и возможность отзыва.