Расскажите про опыт работы с авторизацией

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

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

Как отвечать

Начните с разделения: аутентификация это «кто вы», авторизация это «что вам можно». Дальше по шагам своей схемы:

• вход через свой бэкенд или через внешнего провайдера по OpenID Connect. В браузере это Authorization Code вместе с PKCE, неявный поток больше не рекомендуют;
• хранение сессии. Кука с флагами HttpOnly, Secure и SameSite недоступна скриптам, но требует защиты от CSRF. Токен в localStorage доступен любому выполненному на странице скрипту, то есть любая XSS равна краже сессии. Разумный компромисс: access-токен в памяти, refresh в HttpOnly-куке;
• обновление. Один общий промис на обновление, иначе десяток параллельных запросов получат 401 и одновременно пойдут за новым токеном, а сервер после ротации отзовёт лишние;
• разграничение в интерфейсе: роли приходят от сервера, клиент по ним прячет пункты меню и закрывает маршруты.

Закончите тем, что делали руками: перехватчик на 401, выход сразу во всех вкладках через событие storage, поведение приложения при отозванном токене.

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

Путают аутентификацию с авторизацией и называют OAuth 2.0 способом входа. OAuth выдаёт доступ к чужому API, идентификацию поверх него добавляет уже OpenID Connect, и именно этой разницы ждут в ответе.

Второе: называют хранение токена в localStorage удобным решением и на этом останавливаются. Удобство здесь оплачивается тем, что любая сторонняя библиотека в бандле получает доступ к сессии пользователя.

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