У меня возникают проблемы с поиском правильного выхода из системы с использованием Identity Broker (Keycloak) и Identity Provider (написано с использованием Spring Boot / Security OAuth).
Ниже приведен поток с использованием выхода из обратного канала.:
- Пользователь нажимает кнопку выхода из системы.Это делает запрос к стандартной конечной точке выхода из Keycloak.
- Keycloak вызывает мою конечную точку выхода из Identity Provider (это часть обратного канала; передний канал будет иметь Keycloak, возвращающий 302 здесь и заставляющий браузер вызывать страницу выхода из IdP),Он передает OIDC IdToken, выданный ему моим IdP.
- IdP выполняет следующие действия:
- Делает недействительной сессию
- Удаляет cookie JSESSIONID ... однако этот cookieэто JSESSIONID Keycloak, а не моего браузера, из-за конфигурации обратного канала
- Я мог бы что-то сделать с IdToken здесь, но он не сохраняется (в настоящее время), так как это JWT.
- IdP возвращает 302 на страницу входа
- Keycloak возвращает 302 на страницу входа
Все это работает нормально.Однако, если я перейду прямо на страницу, защищенную безопасностью, я смогу получить к ней доступ без повторного входа. Это потому, что мой сеанс от браузера до IdP никогда не был аннулирован.Когда мой IdP видит, что у него есть сеанс из браузера, он использует учетные данные для входа, которые были введены первоначально (UsernamePasswordAuthToken), и повторно выдает код авторизации в своей конечной точке oauth / authorize, а также перенаправляет на Keycloak.Затем Keycloak принимает этот код авторизации, как обычно, и обменивает его на токен, а затем выдает свои собственные токены.
Вопросы: 1. Я думаю, я мог бы заставить все это работать, если бы смог сделать недействительным сеанс из браузерав IdP.Возможно, переопределив AuthorizationEndpoint в Spring Security OAuth.Но это звучит как взломать.1. Должен ли я использовать выход из переднего канала вместо обратного канала?У меня были другие проблемы с этим (а именно, как Keycloak узнал, что токен, выданный моим IdP, недействителен)