Блог

Я работаю над приложением, которое использует аутентификацию на основе токенов OAuth.

Вот как выглядит поток, учитывая, что у нас есть токен доступа и обновления.

1. Вызов Api -> перехватчик добавляет маркер доступа- > > api возвращает 200
2. Вызов Api -> перехватчик добавляет маркер доступа с истекшим сроком действия- > > api возвращает 401 — > > > перехватчик обновляет маркер с помощью маркера обновления — > > > > перехватчик повторяет тот же запрос — > > > > > возвращает 200
3. Вызов Api -> перехватчик добавляет токен доступа с истекшим сроком действия- > > api возвращает 401 ->>> перехватчик обновляет токен с помощью токена обновления(токен обновления также истек) ->>>> попросите гостя войти в систему ->>>>> гость вошел в систему ->>>>>> повторите запрос

Все это отлично и прекрасно работает — я подумываю немного оптимизировать его, т. е. я не хочу вызывать api и ждать возвращения 401. Вместо этого заранее проверьте срок действия токена, получите новый токен доступа, а затем вызовите api с действительным токеном.

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

Интересно, есть ли лучшее решение, чтобы избежать истечения срока действия времени, основанного на системном времени Android.

Даже если вы добавите такую проверку в свой код, вам все равно понадобится тот поток, который вы представили в вопросе (так что ловите 401s и соответственно обновляйте токены). Это связано с тем, что, как вы заметили, настройки времени на клиентском устройстве могут быть изменены, или может возникнуть небольшой перекос часов между клиентом и сервером (поэтому намеренного изменения настроек времени не требуется).

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

Лично я бы не стал добавлять такую проверку, если бы для этого не было веских аргументов (например, вы знаете, что ваше приложение будет в основном использоваться в удаленных местах с медленными соединениями, и вы хотите ограничить трафик до минимума и т. Д.). Поток, который вы представили, является обычным и работает просто отлично.