Блог

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

Общедоступному клиенту не разрешено выдавать права администратора. Токен доступа недолговечен, а токен обновления имеет бесконечный жизненный цикл.

Конфиденциальному клиенту разрешено выдавать области администратора. Токен доступа недолговечен, а токен обновления живет 24 часа.

Возможно ли, используя Spring Security и их реализацию OAuth2, понизить статус пользователя admin после истечения срока действия токена обновления? То есть, как только пользователь вошел в систему в течение 24 часов, пользователь не полностью выходит из системы, но при следующем входе в систему он получает два новых JWT, один токен доступа для обычного доступа пользователя и один соответствующий токен обновления для этого уровня доступа. Я предполагаю, что я ищу какой-то хук в Spring Security framework, который позволяет мне обрабатывать истечение срока действия токена индивидуальным способом.

_{В вашем вопросе есть предложение, которое меня немного смущает, но я хотел подробнее остановиться на других аспектах, поэтому это не вписывается в комментарий.}

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

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

В соответствии со спецификацией OAuth вы можете выполнить запрос токена обновления и запросить у сервера токен доступа, который имеет меньшие области действия, чем тот, который у вас есть в настоящее время. Однако это также диктует, что если возвращается новый токен обновления, то этот токен должен иметь точно такую же область действия, что и токен обновления, включенный в запрос.

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

Наконец, все еще на тему токенов обновления (с акцентом на раздел «Соображения безопасности«)… когда вы говорите веб-приложение для общедоступного клиента, я предполагаю, что это приложение Javascript на основе браузера. Если это правильно, обычно не рекомендуется использовать токены обновления для этих приложений, потому что токены обновления обычно долговечны (в вашем случае они, похоже, никогда не истекают), и браузер не может обеспечить их безопасное хранение. Это увеличивает вероятность их утечки, что даст злоумышленнику доступ к приложению в течение срока службы токена. У вас могут быть другие ограничения, которые делают это соображение безопасности неприменимым, но, тем не менее, я хотел обратить на это ваше внимание.