Как реализовать авторизацию на фронтенде: хранение access/refresh токенов, отправка запросов и обновление?

Как на фронтенде реализуется авторизация?

• Авторизация представляет собой управление доступом пользователя с помощью токенов.
• Access токен обычно помещают в HttpOnly Cookies, чтобы снизить риск XSS, либо хранят в памяти — это более безопасный вариант.
• Refresh токен сохраняют в HttpOnly Secure Cookies, используя его для обновления access токена без действий со стороны пользователя.
• При обращении к API access токен передается в заголовке Authorization: Bearer.
• Когда срок действия access токена подходит к концу, автоматически вызывается API обновления с использованием refresh токена.
• После успешного обновления новый access токен сохраняется, а выполнение запросов продолжается без повторного входа в систему.
• Для этого применяют JWT или OAuth 2.0, уделяя особое внимание безопасности: защите от XSS и CSRF.

Что важно отметить на интервью:

• LocalStorage подвержен XSS-атакам, поэтому хранить в нем access/refresh токены не рекомендуется
• Cookies с HttpOnly недоступны из JS и считаются оптимальным вариантом для refresh токена
• Настройки CORS и SameSite помогают предотвращать CSRF-атаки
• Необходимо обрабатывать ошибки обновления, включая истекшие или недействительные токены, а также реализовать логаут
• Интерсепторы применяются для автоматической подстановки токена в запросы и выполнения рефреша

Такой ответ показывает, что кандидат понимает современные подходы к безопасной авторизации на клиенте.

Подробный ответ

Основной ответ

На фронтенде авторизацию чаще всего строят вокруг получения и хранения access и refresh токенов, подтверждающих аутентификацию пользователя. После успешного входа сервер возвращает токены, а клиент применяет их при обращении к защищенным API. Access токен используется для аутентификации запросов и действует недолго — обычно около 15–60 минут. Refresh токен позволяет получить новый access токен без повторной авторизации и имеет более продолжительный срок действия — от нескольких дней до недель.

Токены допускается хранить в HttpOnly Cookies или в LocalStorage/SessionStorage, однако предпочтение обычно отдают HttpOnly cookies: они недоступны JavaScript при XSS-атаке и автоматически отправляются браузером на сервер. При этом access токен часто держат в памяти либо в non-persistent хранилище, чтобы уменьшить вероятность его кражи.

Ключевые моменты

• Хранение токенов:
• HttpOnly Secure Cookies недоступны для XSS, автоматически включаются в запросы к тому же домену и рекомендуются для хранения refresh токена.
• LocalStorage/SessionStorage удобны в использовании, но уязвимы при XSS, поэтому токены с расширенными правами лучше в них не сохранять.
• Отправка токенов:
• При обращении к API access токен обычно добавляют в заголовок Authorization: Bearer <token>.
• После истечения access токена refresh токен отправляют для получения нового; как правило, это выполняется через запрос к эндпоинту /refresh.
• Обновление токена:
• Клиент автоматически перехватывает ошибки 401 и отправляет refresh токен, чтобы получить актуальный access токен.
• Для автоматизации этой логики часто применяют интерсепторы axios или обертки над fetch.

Практический контекст

В React 18+ после успешного логина refresh токен обычно сохраняют в HttpOnly cookie с флагами Secure; SameSite=Strict, а access токен размещают в памяти React state или Redux store. Каждый API-запрос получает access токен в заголовке Authorization. Если сервер возвращает 401, клиент обращается к эндпоинту обновления, после чего записывает новый access токен в состояние. Такой вариант помогает совместить безопасность с удобством для пользователя. Для контроля состояния авторизации часто используют глобальные состояния и уведомляют пользователя, когда требуется пройти авторизацию повторно.