В чем разница между аутентификацией и авторизацией

Короткий ответ строится вокруг двух вопросов.

Аутентификация: кто вы. Система проверяет личность пользователя через пароль, одноразовый код, passkey, корпоративный SSO или другой механизм. После успешной проверки появляется сессия, cookie или токен.

Авторизация: что вам можно. Система проверяет, можно ли этому пользователю открыть страницу, прочитать конкретный объект, удалить запись, скачать файл или вызвать административное действие.

Хороший пример для интервью: пользователь вошел в приложение, значит он аутентифицирован. Но если он не администратор, он не должен попасть в админ-панель, значит авторизация должна отказать.

На интервью не нужно начинать с длинного списка протоколов. Лучше сначала дать различие, потом один практический пример, потом сказать про границу ответственности фронтенда.

Можно ответить так:

Аутентификация подтверждает личность пользователя, например при логине. Авторизация проверяет права после входа, например может ли этот пользователь открыть админку или удалить чужую запись. Во фронтенде я могу использовать права, чтобы показать правильный интерфейс, но сервер все равно должен проверять доступ на каждом защищенном запросе.

Такая формулировка звучит безопасно. Вы не обещаете защиту только силами UI.

Фронтенд часто знает часть информации о пользователе: профиль, роли, permissions, scopes. Эти данные нужны, чтобы не показывать лишние элементы и не вести пользователя в закрытые разделы. Но они не должны быть единственным источником истины.

Плохой пример:

function DeleteButton({ user, postId }) {
  if (user.role !== "admin") return null;

  return <button onClick={() => fetch(`/api/posts/${postId}`, { method: "DELETE" })}>Delete</button>;
}

Само скрытие кнопки не плохое. Ошибка появляется, если команда считает это полной защитой. Пользователь может вызвать DELETE /api/posts/:id напрямую, изменить роль в клиентском состоянии или повторить запрос из другого клиента. Если UI еще и делает optimistic update без обработки 403, запись исчезнет на экране, хотя сервер ее не удалил.

Безопаснее так: API проверяет право на удаление на сервере, фронтенд показывает кнопку только для удобства, обрабатывает loading и error, а при отказе откатывает optimistic UI. Если авторизация основана на cookie-сессии, запросы, которые меняют данные, должны быть защищены от CSRF на уровне сервера, например через SameSite и CSRF-токен.

Безопасная мысль для ответа: UI использует авторизацию для удобства, сервер использует авторизацию для защиты.

Токен или сессия обычно связаны с аутентификацией, потому что позволяют серверу узнать пользователя в следующих запросах. Но внутри токена могут быть claims, которые помогают авторизации: роль, tenant, scope, список разрешений.

Важно не сказать, что наличие JWT автоматически решает авторизацию. Сервер должен проверить подпись токена, срок жизни, аудиторию, issuer и право на конкретное действие. Для критичных операций может потребоваться проверка актуального состояния в базе, потому что роль могли отозвать после выдачи токена.

На фронтенде это значит: не надо безусловно доверять старому user.role из кеша. Если API вернул 403, обновите состояние доступа, покажите понятное сообщение и не делайте optimistic UI успешным без подтверждения.

Эти статусы помогают показать, что вы понимаете практику.

401 Unauthorized обычно означает проблему с аутентификацией. Пользователь не вошел, токен истек, cookie недействительна. Возможные действия фронтенда: попробовать refresh token flow, отправить на логин, очистить локальное состояние сессии.

403 Forbidden означает, что пользователь известен, но доступ запрещен. Возможные действия: оставить пользователя в системе, убрать недоступное действие, показать сообщение вроде "У вас нет доступа к этому разделу" и не раскрывать детали защищенного ресурса.

Риск ошибки: если вы всегда разлогиниваете при 403, пользователь не понимает, почему потерял сессию. Если вы всегда показываете общий toast, вы теряете шанс корректно восстановить сессию при 401.

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

Для короткого ответа достаточно так:

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

Это сильный плюс, но не уходите в протоколы, если основной вопрос был только про различие аутентификации и авторизации.

В ответе важно показать не только определение, но и последствие для кода. Аутентификация дает приложению понимание, кто сейчас работает. Авторизация ограничивает действия этого пользователя. Фронтенд помогает сделать интерфейс понятным, но не является надежной границей безопасности.

Если вы проектируете экран, задайте себе три вопроса: можно ли показывать эти данные до проверки, что делать при 401, что делать при 403. Такой подход снижает риск утечек, неверного optimistic UI и странного поведения при изменении прав.