#oauth-2.0 #access-token #interceptor #refresh-token #rfc6749
#oauth-2.0 #токен доступа #перехватчик #обновить-токен #rfc6749
Вопрос:
Я внедряю сервер авторизации oauth2.
При использовании токена обновления обмена oauth2 на токен доступа (rfc6749) у моего клиента — мобильного приложения возникли проблемы с реализацией перехватчика (по многим причинам).
Как и раньше, мой клиент выполняет поток обмена токенами (rfc8693), и токен доступа сохраняется в базе данных, поэтому я решаю вернуть ТЕКУЩИЙ токен доступа (ТОЛЬКО если он все еще действителен) вместо выдачи нового токена доступа при каждом получении токена обновления.
Время жизни токена доступа короткое (около 5 минут), и пользователь может отозвать как токен доступа, так и токен обновления.
Но это решение противоречит rfc6749, в котором указан новый токен доступа:
Сервер авторизации проверяет подлинность клиента и проверяет токен обновления, и, если он действителен, выдает новый токен доступа (и, необязательно, новый токен обновления)
Мне интересно, может ли это решение привести к каким-либо проблемам?
Ответ №1:
Как вы отметили, это само по себе является нарушением спецификации. Цель спецификации — сделать что-то полезное при запросе токена обновления. В вашем случае запрос токена обновления не имеет никакого смысла, поскольку токен доступа фактически не обновляется. Таким образом, лучший подход для вашего варианта использования — не заставлять клиента обновлять токен доступа, пока он все еще действителен. Однако предлагаемый подход не приводит к каким-либо проблемам, кроме нарушения спецификации и, возможно, несовместимости с некоторыми клиентами.