Мне нужно понять, как избежать или как управлять липкой сессией во время OAuth2 — Предоставление потока кода авторизации, в частности во время: GET /uaa/oauth/authorize, POST /uaa/login и еще раз GET /uaa/oauth/authorize
Наша служба аутентификации будет обслуживать только два принадлежащих нам веб-приложения, каждое из которых является ресурсным сервером с проверкой токена и валидности. Если токена нет или он недействителен, они будут перенаправлены непосредственно на страницу входа в систему Auth Server (правда, говоря о первом вызове, GET /oauth/authorize).
Для предоставления кода авторизации Flow Grant необходимо выполнить следующие шаги:
-Первый вызов для регистрации клиентского запроса GET /uaa/oauth/authorize, сохранение в сеансе (в моем случае Spring Redis) некоторой информации, например callbackurl клиента
-Второй вызов для входа в систему с помощью учетных данных пользователя POST /login
-Третий вызов для получения ACCESS_CODE GET /uaa/oauth/authorize, получение URL-адреса обратного вызова из сеанса.
Но что, если я подделаю два запроса от двух разных клиентов, открыв в одном браузере две разные вкладки?
Например, с:
http://localhost:9191/uaa/oauth/authorize?response_type=code&client_id=client-one&scope=auth&redirect_uri=http://localhost:8080/client-one
а другой с:
localhost:9191/uaa/oauth/authorize?response_type=code&client_id=client-two&scope=auth&redirect_uri=http://localhost:8080/client-two
Весенняя сессия становится грязной. Например:
Я безуспешно пытался настроить SessionRepository, но, используя другие сервисы с Oauth2, я начинаю верить, что мне понадобится хотя бы одна страница в каждом веб-приложении, прокси перед первым вызовом GET/oauth/authorize.
Есть ли какие-либо рекомендации, чтобы избежать липкого сеанса с этим потоком?
Или какой-то способ управлять несколькими вкладками без html-страницы? Spring-Security по умолчанию использует липкую сессию.
Спасибо за уделенное время.
В итоге я реализовал что-то вроде nonce, по умолчанию не поддерживаемого Spring Security (насколько мне известно, Весенняя безопасность GitHub).
Если пользователь пытается аутентифицироваться с одноразовым номером, отличным от последнего, я выкидываю его на страницу с ошибкой с сообщением типа «сеанс входа в систему истек» со ссылкой на веб-приложение.