Аутентификация OAuth2 в React
Сделаем полноценный клиент аутентификации в React для получения токенов JWT с бэкенда по протоколу OAuth2 с PKCE. Рассмотрим подходы к автообновлению токенов и нюансы безопасности. Добавим возможность действия от имени пользователя в E2E-тестах.
- 00:01:38 Компонент AuthProvider
- 00:03:18 Защита от атак с помощью state
- 00:06:26 Параметры для провайдера
- 00:10:15 Страница состояния аутентификации
- 00:10:41 Страница ожидания
- 00:14:54 Придумывание значений контекста
- 00:18:32 Контекст и черновик
- 00:19:43 Мемоизация значений
- 00:21:51 Хук useAuth
- 00:22:21 Тесты отображения кнопок
- 00:23:59 Мемоизация функции с useCallback
- 00:24:55 Процесс входа
- 00:26:48 Генерация Code Challenge
- 00:29:25 Редирект на authorize
- 00:32:45 Тест логина
- 00:33:44 Обработка обратного редиректа
- 00:35:29 Состояние провайдера
- 00:38:35 Вывод первоначальной ошибки
- 00:41:38 Проверка state
- 00:42:44 Получение токенов по коду
- 00:48:20 Хранение токенов и безопасность
- 00:51:44 Сохранение данных
- 00:56:45 Повторный рендер при Strict Mode
- 00:59:03 Тестирование редиректа
- 01:01:12 Кнопка выхода
- 01:02:21 Синхронизация разных вкладок
- 01:05:57 Метод getToken для запросов в API
- 01:07:11 Подходы к обновлению токена
- 01:12:10 Оптимизация подходов
- 01:17:09 Обновление истёкшего токена
- 01:19:17 Возврат Promise
- 01:21:08 Избавление от конфликтов
- 01:23:57 Нюансы возврата промиса
- 01:25:16 JWT-токен в E2E-тестах
- 01:29:24 Генерация JWT на бэкенде
- 01:30:51 Отдельные тестовые сценарии
- 01:32:31 Работа с другими доменами
И в следующем эпизоде раберёмся с переменными окружения для фронтенда.
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо!
Спасибо.
Дмитрий, здравствуйте, а будет отдельно урок как повысить безопасность форм входа и регистрации, защитить от разных типов атак, в том числе от угона refresh_token? Не совсем понятно почему из всех подходов остановились здесь на хранении refresh_token в LocalStorage.
Эффективнее всего все эти формы cделать на бэкенде, отключить им CORS-заголовки и защищать CSRF-токенами и капчей, чтобы их не спамили и не подбирали из JS-кода с других сайтов. И для защиты от перебора сделать Rate Limit, временно блокируя форму после нескольких ошибок.
Но от целенаправленных атак спама или подбора это всё равно не спасёт. Спамер завалит сайт запросами в цикле через любой HTTP-клиент или браузер в PuppeteerJS и сделает распознавание капчи.
Это обсуждали в комментариях к первому эпизоду про OAuth.
Для защиты от угона рекомендуют серверу ауетентификации возвращать
refresh_tokenчерезSet-Cookieс привязкой к своему путиpath=/tokenи сhttpOnly=true. А потом Ajax-запрос на обновление токена делать сallowCredentials=true, чтобы браузер передавал эту куку с токеном. Так токен будет полностью недоступен из JavaScript и никакой сторонний JS-код не сможет его узнать.И заодно на стороне бэкенда можно добавить блокировку
refresh_tokenесли пришёл повторный запрос на обновление с этим же токеном.Это самый лёгкий вариант. Его стоит бояться если на нашем сайте может оказаться чужой JS-код, который отправит хозяину содержимое нашего LocalStorage. У нас по умолчанию React экранирует весь выводимый контент. И мы не будем подключать посторонние скрипты. Так что это для нас не так критично.
Дмитрий, спасибо огромное за развернутый ответ, отлично проясняет данные моменты эпизода. А для защиты от целенаправленных атак спама или подбора что можете порекомендовать, если возможно?
Если хакеру много заплатят, то он арендует себе тысячу прокси-серверов и напишет нейронку для разгадывания любой капчи. Либо напрямую взломает сервер. Либо устроится на работу на испытательный срок по поддельным документам, чтобы залить закладку и уйти. Либо шантажом завербует программиста компании, чтобы всё слить через него. Угрозы бывают разные. От всего не защитишься.
Согласен, не все угрозы безопасности закрываются только техническими решениями, спасибо за апдейт.
Или войти через: