С какими системами авторизации работал

Вопрос "С какими системами авторизации работал" лучше не воспринимать как просьбу перечислить все знакомые названия. Хороший ответ показывает три вещи: с чем вы реально работали, какую часть делали на фронтенде и какие риски учитывали.

Держите простую структуру:

1. Назовите схему: cookie session, JWT, OAuth 2.0, SSO, Firebase Auth, Cognito или другое.
2. Объясните вашу роль: login, callback, protected routes, refresh, logout, роли, обработка ошибок.
3. Добавьте практический риск: XSS, CSRF, истечение токена, гонки refresh, server-side permission check.
4. Не придумывайте опыт. Лучше честно сказать "интегрировал готовый SDK" или "делал учебный flow", чем уверенно заявить то, что не сможете объяснить.

Если у вас был коммерческий опыт, можно ответить так. Замените стек и детали на свои:

В последнем проекте я работал с авторизацией на базе JWT и refresh token. На фронтенде делал форму входа, хранение состояния пользователя, защищенные маршруты, обработку 401 и logout. Access token был короткоживущим, refresh обновлялся через отдельный endpoint. Для ролей мы скрывали недоступные действия в UI, но права обязательно проверялись на API.

Если вы подключали OAuth или SSO:

Также интегрировал вход через внешнего провайдера. На клиенте обрабатывал redirect callback, состояние загрузки и ошибки, а обмен кода на сессию шел через бекенд. Я понимаю, что во фронтенде нельзя хранить client secret, поэтому для SPA важен PKCE и проверка state.

Если опыт небольшой, лучше не преувеличивать:

В продакшене я пока не проектировал auth с нуля, но интегрировал готовый провайдер и понимаю клиентскую часть: protected routes, состояние пользователя, logout, обработку 401 и ограничения хранения токенов в браузере.

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

Неудачная формулировка:

Мы проверяли роль на фронтенде, поэтому обычный пользователь не мог вызвать админское действие.

Проблема в том, что пользователь может открыть DevTools, вызвать API напрямую или изменить локальное состояние. Лучше сказать так:

На фронтенде мы скрывали админские действия и защищали route для UX, но API все равно проверял роль на сервере. Если сервер возвращал 403, клиент показывал понятную ошибку и не обновлял интерфейс как будто операция прошла.

В ответе важно не продавать один способ хранения как единственно правильный. У каждого варианта есть цена.

HttpOnly cookie не прочитает JavaScript, поэтому при XSS сложнее украсть сам токен. Но cookie автоматически отправляется браузером, значит нужно думать про SameSite, CSRF-токен или BFF-подход.

localStorage прост для SPA, но токен доступен любому скрипту на странице. In-memory хранение не сохраняет токен между перезагрузками, но XSS все равно может выполнить запрос от имени пользователя. Если в проекте был такой вариант, не защищайте его как идеальный. Скажите, почему его выбрали, какой TTL был у access token, какие меры были против XSS и как UI восстанавливал сессию после reload.

Частая ловушка на интервью: вы говорите "если пришел 401, обновляем токен", но не объясняете, что будет при нескольких параллельных запросах. В реальном интерфейсе после открытия страницы может одновременно уйти несколько запросов, и все они получат 401.

Плохой пример, так делать рискованно:

api.interceptors.response.use(undefined, async (error) => {
  if (error.response?.status === 401) {
    await refreshToken();
    return api.request(error.config);
  }

  throw error;
});

Что сломается: каждый запрос с 401 запустит свой refresh, токены могут перезаписаться в случайном порядке, а исходные запросы уйдут повторно несколько раз. В UI это выглядит как мигающий loading, внезапный logout или успешное действие, которое потом откатывается ошибкой.

Более безопасная идея: держать общий promise обновления, ждать его в остальных запросах, помечать исходный запрос как уже повторенный, отменять или не повторять запросы после logout и выходить в единое состояние unauthenticated, если refresh не прошел.

Если вы говорите про OAuth, не сводите ответ к фразе "вошли через Google". Для фронтенда важны redirect, callback, state, обработка ошибок, состояние загрузки, возврат пользователя на исходную страницу и связь с бекенд-сессией.

Для SPA полезно упомянуть Authorization Code Flow with PKCE. Так вы показываете, что понимаете ограничение браузерного клиента: он публичный и не может безопасно хранить client_secret. Если проект использовал готовый SDK, скажите, какую часть делал SDK, а какую вы контролировали в приложении.

На собеседовании не нужно называть максимальное число систем. Важнее показать зрелость: вы понимаете границы фронтенда, не выдаете UI за защиту API, знаете риски хранения токенов и умеете поддержать нормальный пользовательский flow.

Хорошая короткая версия ответа может звучать так:

Работал с JWT и cookie-based сессиями, также интегрировал OAuth-провайдера. На фронтенде отвечал за login flow, состояние пользователя, protected routes, refresh, logout и обработку 401/403. При выборе хранения токенов смотрю на риски XSS и CSRF, а проверку прав всегда оставляю на сервере. Если бы проектировал новый SPA-flow, рассматривал бы Authorization Code Flow with PKCE или BFF, в зависимости от требований безопасности.

Адаптируйте эту фразу под свой реальный опыт. Если чего-то не делали, не включайте это в ответ как факт.