Задонатить и смотреть →
Открой безлимитный доступ к 100+ полезных скринкастов и получай скидки на все предстоящие мероприятия

Аутентификация 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
Комментарии (7)
fedot

Спасибо!

Ответить
Arunas

Спасибо.

Ответить
Руслан

Дмитрий, здравствуйте, а будет отдельно урок как повысить безопасность форм входа и регистрации, защитить от разных типов атак, в том числе от угона refresh_token? Не совсем понятно почему из всех подходов остановились здесь на хранении refresh_token в LocalStorage.

Ответить
Дмитрий Елисеев

как повысить безопасность форм входа и регистрации

Эффективнее всего все эти формы cделать на бэкенде, отключить им CORS-заголовки и защищать CSRF-токенами и капчей, чтобы их не спамили и не подбирали из JS-кода с других сайтов. И для защиты от перебора сделать Rate Limit, временно блокируя форму после нескольких ошибок.

Но от целенаправленных атак спама или подбора это всё равно не спасёт. Спамер завалит сайт запросами в цикле через любой HTTP-клиент или браузер в PuppeteerJS и сделает распознавание капчи.

в том числе от угона refresh_token

Это обсуждали в комментариях к первому эпизоду про OAuth.

Для защиты от угона рекомендуют серверу ауетентификации возвращать refresh_token через Set-Cookie с привязкой к своему пути path=/token и с httpOnly=true. А потом Ajax-запрос на обновление токена делать с allowCredentials=true, чтобы браузер передавал эту куку с токеном. Так токен будет полностью недоступен из JavaScript и никакой сторонний JS-код не сможет его узнать.

И заодно на стороне бэкенда можно добавить блокировку refresh_token если пришёл повторный запрос на обновление с этим же токеном.

Не совсем понятно почему из всех подходов остановились здесь на хранении refresh_token в LocalStorage.

Это самый лёгкий вариант. Его стоит бояться если на нашем сайте может оказаться чужой JS-код, который отправит хозяину содержимое нашего LocalStorage. У нас по умолчанию React экранирует весь выводимый контент. И мы не будем подключать посторонние скрипты. Так что это для нас не так критично.

Ответить
Руслан

Дмитрий, спасибо огромное за развернутый ответ, отлично проясняет данные моменты эпизода. А для защиты от целенаправленных атак спама или подбора что можете порекомендовать, если возможно?

Ответить
Дмитрий Елисеев

Если хакеру много заплатят, то он арендует себе тысячу прокси-серверов и напишет нейронку для разгадывания любой капчи. Либо напрямую взломает сервер. Либо устроится на работу на испытательный срок по поддельным документам, чтобы залить закладку и уйти. Либо шантажом завербует программиста компании, чтобы всё слить через него. Угрозы бывают разные. От всего не защитишься.

Ответить
Руслан

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

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu