JWT-токен+RF-токен концепция

Читаю про данную технологию, возникло пару вопросов.

Допустим есть сервис авторизации(далее СА) и сервис ресурсов(далее СР) и мобильное приложение(далее МП). МП отправляет на СА логин/пароль, СА проверяет, находит нужного человека, генерит RF-токен и Access-токен(JWT внутри пусть Id-пользователя/дату окончания и еще какая-либо служебная информация), кладет в БД связку RF-токен и ID-пользователя, возвращеет МП.

Затем МП отправляет access-токен и свой запрос(например дай баланс) на СР. СР валидирует подпись, видит что верная, берет из тела Id-пользователя, проверяет дату окончания и выполняет для него запрос, если токен просрочен, то возвращает ошибку МП.

МП в свою очередь делает запрос обновления в СА(отправляя RF-токен,Access-токен). СА проверяет наличие RF-токена в БД и пользователя, если все гуд генерит новую пару RF/access-токен возвращает МП.

Предполагается допустим жизнь access-токена 10 минут. Но тогда получается раз в 10 минут будет выполняться дорогая операция общения с СА?

Возможно ли сделать что время протухания было плавающим(т.е. если обратились к СР то время протухания = время протухания+5минут)? Если да то как и кто это должен делать? Ведь СР(если допустим мы используем RSA) может только проверить подпись, новый access-токен он не сгенерит?

Опять же, если да, то как такой токен отозвать?(Допустим мы убили RF-токен он был скомпрометирован, но СР об этом не узнает, до тех пор пока access-токен не протухнет, а если дата протухания плавающая, то окно становится большим)

Или я чего-то не понял? Или это используется как-то по другому?

Буду рад любым комментариям, которые натолкнут на мысль, где я не правильно понял)