Что такое аутентификация

Аутентификация нужна, чтобы система поняла, кто делает запрос. Это может быть человек, сервис, устройство или другое приложение. В обычном веб-приложении пользователь доказывает личность через пароль, одноразовый код, passkey, корпоративный SSO или внешний identity provider.

На интервью удобно отвечать в два шага. Сначала дайте определение. Потом сразу отделите его от авторизации. Если сказать только, что это вход в систему, ответ будет слишком бытовым. Лучше добавить, что после входа еще нужно отдельно проверить права на конкретное действие.

Frontend не должен быть источником истины для безопасности. Он показывает состояние входа, скрывает недоступные элементы, отправляет запросы с cookie или token и обрабатывает ошибки. Но решение, можно ли читать эти данные или можно ли удалить этот объект, принимает сервер.

Хорошая короткая формулировка:

Аутентификация подтверждает личность пользователя, например через пароль, MFA или провайдера. После нее приложение получает сессию или токен, а авторизация уже определяет доступы. На фронтенде я слежу, чтобы credentials передавались безопасно, не доверяю только UI-проверкам и корректно обрабатываю истечение сессии.

Этот flow важен, потому что ошибки в аутентификации часто проявляются не при первом входе, а позже. Например, пользователь оставил вкладку открытой на ночь, access token истек, приложение продолжает показывать приватные данные из кеша и все запросы падают с 401. Если вы упоминаете такие сценарии, ответ звучит практичнее.

Пример ниже не показывает всю production-схему. Он показывает важную мысль: после логина фронтенд не должен сам назначать роль или считать JWT окончательной проверкой прав. Он отправляет данные на сервер, затем запрашивает профиль и обрабатывает отказ.

async function login(email: string, password: string, signal?: AbortSignal) {
  const response = await fetch("/api/login", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    credentials: "include",
    signal,
    body: JSON.stringify({ email, password }),
  });

  if (!response.ok) {
    throw new Error("Не удалось войти");
  }

  const profileResponse = await fetch("/api/me", {
    credentials: "include",
    signal,
  });

  if (profileResponse.status === 401) {
    throw new Error("Сессия не активна");
  }

  if (!profileResponse.ok) {
    throw new Error("Не удалось получить профиль");
  }

  return profileResponse.json();
}

Здесь credentials: "include" нужен, если backend использует cookie-сессию или cookie с токеном. Если проект использует bearer token, контракт будет другим. В любом случае проверка личности и прав остается на backend, а frontend должен корректно реагировать на статусы и не хранить лишние секреты.

В React такой вызов обычно оборачивают в состояние формы: отключают кнопку на время запроса, показывают ошибку рядом с полями и отменяют устаревший запрос через AbortController при уходе со страницы. Иначе возможны лишние login-запросы, race condition между старым и новым ответом или обновление состояния уже размонтированного компонента.

JWT - это формат токена, а не автоматическая безопасность. Его можно подписать, ограничить по времени, проверить по issuer и audience, но при утечке он все равно может дать доступ до истечения срока. Поэтому важно говорить про короткий срок жизни, refresh-механику, logout и отзыв, если он нужен продукту.

Cookie-сессия тоже не идеальна сама по себе. httpOnly cookie защищает от чтения токена через JavaScript, но браузер будет отправлять cookie автоматически. Поэтому нужно учитывать CSRF, SameSite, Secure и доменную модель. Сильный ответ не спорит cookie против JWT абстрактно, а объясняет условия выбора.

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

Практический ответ может быть таким: для login через провайдера обычно используют OpenID Connect. OAuth помогает выдать доступ, а OIDC позволяет приложению понять, кто пользователь. Это коротко и показывает, что вы не смешиваете протоколы.

На интервью вам не нужно проектировать всю identity platform. Достаточно показать границы ответственности. Backend проверяет credentials, выдает сессию или токены, проверяет доступ на API. Frontend отправляет запросы по контракту, не хранит секреты без необходимости, защищается от типичных browser-угроз и держит понятный UX при ошибках.

Если хотите усилить ответ, добавьте пример риска. Например: если хранить долгоживущий access token в localStorage, XSS может его украсть. Если полагаться только на скрытие кнопки, пользователь сможет дернуть API напрямую. Поэтому разделяйте UX-ограничения на клиенте и настоящие проверки на сервере.