Существует множество способов обработки аутентификации в вашем веб-приложении. Все без исключения методы имеют свои плюсы и минусы, вы можете изучить и выбрать тот, который подходит вам в соответствии с вашими вариантами использования.
Однако, если вы уже выбрали аутентификацию с использованием токена обновления, эта статья для вас.
Вернемся к некоторым понятиям
Прежде чем перейти к статье, давайте вспомним, как токен обновления (RT) и токен доступа (AT) работают для аутентификации.
Токен доступа. Токен доступа — наш главный герой, он будет использоваться для аутентификации вызовов API, поступающих из внешнего интерфейса.
Токен обновления:Токен обновления — это наш герой поддержки, который сам по себе не может аутентифицировать какой-либо вызов API, но когда срок действия токена доступа истекает, он поможет нам получить новый токен доступа из службы, для выполнения этой задачи время истечения срока действия токена обновления должно быть больше, чем срок действия токена доступа.
Некоторое предположение
Постараюсь охватить концепции как можно более общим образом. Прежде чем приступить к основным понятиям, давайте определим некоторые базовые предположения.
- В этой статье мы предполагаем, что серверная служба уже запущена, и сосредоточимся только на реализации внешнего интерфейса.
- Для простоты написания я буду хранить токен в локальном хранилище браузера на стороне клиента, вы можете выбрать, где вы хотите его хранить.
- Я буду использовать Axios для вызовов API к серверной части, вы можете выбрать свой любимый метод для вызова API и реализовать данный подход на своем уровне.
Приступим к действию
Концепция довольно ясна, мы должны создать механизм для связи с серверной частью, чтобы получить новый токен доступа, когда срок его действия истечет.
Использование JS-таймера
С первым вызовом, когда мы получаем AT и RT, мы можем подписаться на 5-минутный таймер (равный истечению срока действия AT), как только он истечет, мы сделаем вызов API к серверной части и получим новый AT и RT и продолжим поток.
Приведенный выше подход выглядит нормально, но давайте предположим, что пользователь открыл ваше приложение на 3 вкладках в браузере, теперь есть 3 таймера, работающих независимо друг от друга, и как только установленный таймер завершится, вызовы API любого из таймеров перейдут к серверной части для новых AT и RT. Пожалуйста, обратитесь к приведенному ниже потоку, чтобы понять, какую возможную проблему это может вызвать.
Кроме того, таймер — это дополнительный процесс, который выполняется браузером в фоновом режиме, поэтому это дополнительные накладные расходы, поскольку по мере увеличения количества вкладок приложения количество таймеров будет увеличиваться.
Следовательно, таймер JS усугубит проблему, а не решит ее.
Использование перехватчиков API
Прежде чем перейти к этому, давайте разберемся, что такое перехватчик.
Запрос, поступающий к серверной части, или любой ответ, поступающий от серверной части, проходит через дополнительный уровень, известный как перехватчик API.
Преимущество этого уровня в том, что он может преобразовывать исходящие запросы и входящие ответы, а препроцессоры могут быть размещены перед продолжением фактического потока.
Основная логика
Итак, теперь вы, должно быть, поняли, что мы пытаемся здесь сделать. давайте посмотрим на схему для большей ясности.
Как вы можете видеть, мы делаем новый вызов API AT только тогда, когда получаем ошибку 401.
Как настроить перехватчик Axios?
Это очень просто, вы можете следить за официальной документацией Axios.
Итак, как вы думаете, проблема решена?
Нет, все же есть один случай, который мы здесь упускаем, в случае параллельных вызовов API, все из которых содержат токен доступа с истекшим сроком действия, нам пришлось бы получить вызов токена обновления только один раз и повторить все вызовы с истекшим сроком действия.
Обработка параллельных вызовов API
Чтобы обработать вышеуказанный случай, мы будем использовать технику pub-sub, где мы подпишемся на ответ на вызов API токена обновления, и как только мы его получим, мы снова сделаем все неудачные вызовы API один за другим и решим обещание.
приведенный выше код вызовет getNewAccessToken только один раз и повторит попытку всех неудачных API в том же порядке, в котором они потерпели неудачу.
Это всего лишь одна концепция, может быть N способов, которыми вы можете реализовать аутентификацию с токеном обновления.
Надеюсь, вы поняли концепцию обработки аутентификации с помощью токена обновления. Любые предложения или исправления в этой статье приветствуются. Вернусь с еще одной интересной статьей. Удачного кодирования до тех пор! ❤
Дополнительные материалы на PlainEnglish.io.
Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord.
