Приходилось ли реализовывать авторизацию на фронте или бэке

Что проверяют

Понимаете ли вы, что фронтенд ничего не защищает: он прячет кнопку, а решение принимает сервер. Дальше слушают, различаете ли аутентификацию и авторизацию и что происходит с токеном после протухания. Уточнение почти всегда одно: «где вы храните токен и как его обновляете».

Как отвечать

Опишите схему, которая была у вас, целиком:

• сессия с кукой: сервер ставит httpOnly и Secure куку, фронт про неё не знает; при SameSite=Lax нужен CSRF-токен, при кросс-доменном API SameSite=None и аккуратный CORS с credentials;
• пара токенов: короткоживущий access в памяти вкладки (обычно от пяти до пятнадцати минут) и refresh в httpOnly-куке с ротацией и обнаружением повторного использования;
• внешний провайдер: OpenID Connect поверх OAuth 2.1, поток Authorization Code с PKCE, implicit больше не применяется.

Дальше клиентская механика, которая отличает практика от теоретика. Единая обёртка над fetch или интерсептор axios, который на 401 запускает обновление и ставит остальные запросы в очередь, чтобы десять параллельных вызовов не выпустили десять refresh. Выход из аккаунта, когда обновление не удалось. Синхронизация вкладок через BroadcastChannel.

Про роли скажите отдельно: гварды маршрутов и условный рендер по scope это удобство, а не защита. Тот же признак сервер проверяет самостоятельно, иначе достаточно открыть вкладку сети и позвать ручку руками.

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

Где спотыкаются

Отвечают «храним JWT в localStorage, так все делают». Любой XSS уносит токен целиком, а отозвать его без списка отзыва нельзя. Про этот компромисс нужно хотя бы знать.

Считают скрытую кнопку защитой. Классический провал: интерфейс не показывает административный раздел, но GET /api/admin/users отдаёт данные любому с валидным токеном.

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