Клиент Spring OAuth2 выполняет выход из обратного канала с истекшим идентификатором токена

что это за токен oidc_id_token/id_token_hint

id_token_hint — это рекомендуемый параметр запроса на выход, отправляемого на сервер авторизации, как определено в спецификации выхода из системы, инициируемого RP.

напишите собственный репозиторий токенов, который не будет обновлять поле клиентского токена (oidc_id_token). Но я считаю, что это плохое решение.

Да, это плохое решение. Серверу авторизации было бы очень неудобно выдавать токены с истекшим сроком действия.

Как и в случае со всеми JWT, срок действия токенов ID истекает, даже если их срок службы обычно больше, чем у токенов доступа. Поэтому, когда токены обновляются, все это должно быть обновлено (все, кроме токена обновления, если вы хотите принудительно выполнить новый вход после истечения срока действия исходного токена обновления). В спецификации выхода из системы, инициируемого RP, указано, что сервер авторизации ДОЛЖЕН принять просроченный id_token_hint, что означает, что рекомендуется это сделать, но у вас нет гарантии, что так и будет. Поэтому просто попросите клиента отправить действительный токен идентификатора (с требованием exp в будущем).

но клиент (spring-oauth2-client + шлюз) не обновляет этот токен

Бывает, иногда...

Токены обновляются при доступе с помощью (Reactive)OAuth2AuthorizedClientManager. К сожалению, OidcClientInitiated(Server)LogoutSuccessHandler внутренне использует (Reactive)ClientRegistrationRepository, который не обновляет токены с истекшим сроком действия. Я открыл заявку, чтобы исправить это, но приоритет еще не установлен. Я предполагаю, что с выпуском SpringOne на следующей неделе команда Spring Security спешит отшлифовать то, что было запланировано в следующем этапе и выпуске.

Хорошей новостью является то, что существует простой обходной путь при использовании Spring Cloud Gateway с фильтром TokenRelay, поскольку этот фильтр использует ReactiveOAuth2AuthorizedClientManager. Поэтому, если вы отправите фиктивный запрос, маршрутизируемый с помощью TokenRelay, непосредственно перед вызовом конечной точки выхода из системы, то токены будут обновлены, и выход из системы будет выполнен с действительным токеном идентификатора.

В моих приложениях:

• бэкэнды предоставляют конечную точку /me, которая отражает некоторые требования токена доступа — минимум имени пользователя, полномочий и срока действия токена доступа.
• Интерфейсные приложения планируют новый вызов к этой конечной точке незадолго до истечения срока действия токена доступа (в течение последней минуты). Этот:
  • принудительно обновляет токен. Я никогда не сталкивался с проблемой, о которой вы здесь сообщаете, потому что все токены обновляются до истечения срока их действия.
  • всегда предоставляет интерфейсу ту же информацию о доступе пользователя, что и ресурсный сервер (ресурсные серверы принимают решения по управлению доступом на основе токена доступа): если роли изменяются на сервере авторизации, это вступит в силу на ресурсном сервере( s) когда токен доступа обновляется
  • сохраняет сеанс клиента OAuth2 активным, так что сеанс пользователя контролируется только сеансом сервера авторизации.