Заранее извиняюсь за этот длинный пост.Я старался быть как можно более ясным, потому что, возможно, мое понимание некоторых понятий неверно
В рамках моего путешествия в мир микросервисов я экспериментирую с созданием набора служб, связанных с федеративной идентификацией, предоставляемой экземпляром Identity Server 4 ( OIDC и OAuth2 framework для ASP.NET Core).У меня есть несколько React SPA (в терминах OIDC это проверяющие стороны или RP), которые делегируют аутентификацию моему провайдеру идентификации (OP), где пользователю предоставляется доступ к любому из ряда ресурсов API.
Для управления частью потока OIDC мои приложения React используют библиотеку redux-oidc и поток implicit.Это служит для обеспечения того, чтобы приложение могло доверять своему пользователю и совершать авторизованные вызовы внутренних API-интерфейсов от имени пользователя.Однако полный поток OIDC выполняется на стороне клиента и заканчивается сохранением токенов в браузере, что означает, что доверие сохраняется только до истечения времени истечения токена.
Я пытаюсь достичь следующего сценария: если пользователь вошел в приложение и явно не вышел из приложения или централизованного поставщика удостоверений, его сеанс в приложении нене истекает, если не прошло заранее установленное время (дни, а не минуты).Идея состоит в том, что приложение предоставляет кнопку «Выход», которая дает пользователю возможность выхода только из приложения или всей экосистемы федеративной идентификации.В обоих случаях они должны впоследствии щелкнуть Вход в приложении (но только в последнем случае им придется повторно пройти аутентификацию на OP).
Вернуться к моей реализации.Совершенно верно, что неявный поток не делает токен обновления доступным.Однако существует концепция тихого обновления , которая, как я понимаю, позволяет скрытому iFrame на странице отправлять запросы фоновой аутентификации обратно в OP с помощью prompt=none строки запроса.Теория заключается в том, что до тех пор, пока один и тот же пользователь все еще входит в OP, генерируется новый набор токенов, который автоматически заменяет те, которые кэшируются в браузере.Вдобавок к этому есть концепция OIDC проверки сеанса , которая, по моему пониманию, предназначена для того, чтобы позволить RP проверять, что аутентифицированное состояние его текущего пользователя не изменилось на OP.
Я бы подумал, что смогу использовать эти концепции вместе, чтобы достичь того, чего я хочу.Тем не менее, я не могу заставить все это держаться вместе.Я объясню.
Библиотека redux-oidc предоставляет абстракции для этих понятий.При включенном автоматическом обновлении я могу наблюдать, что после аутентификации через определенные промежутки времени в DOM добавляется iFrame с конечной точкой OP connect/authorize в качестве src.Я также могу заметить, что токен доступа, сохраненный в браузере, обновляется с новым временем истечения.Так что это хорошо - как только у пользователя будет активная сессия, он не будет неожиданно выгнан.
Если я закрою приложение во время сеанса с проверкой подлинности, а затем быстро вернусь, приложение загрузится с пользовательской сессиейактивный.Журнал Redux показывает действия redux-oidc/LOADING_USER, затем redux-oidc/USER_FOUND запускаются.Я предполагаю, что это второе действие следует за ответом от checksession iFrame, но я не уверен в этом.На этом этапе возобновляется беззвучное возобновление и сохраняет сеанс свежим.
Однако, если я закрою приложение дольше, прежде чем вернуться, я наблюдаю следующие действия: redux-oidc/LOADING_USER затем redux-oidc/USER_EXPIRED.На этом этапе пользователь должен инициировать новое обратное путешествие к OP, даже если его сеанс на OP не изменился.
Насколько я могу судить, время, которое мне нужно ждать, прежде чем наблюдать за этим вторым сценариемпривязан ко времени истечения срока действия моих токенов доступа.Если я установлю время истечения 10 секунд, а затем закрою приложение на 11 секунд, мой сеанс пользователя уже истек.Тем не менее, я думал, что целью проверки сеанса OIDC является подтверждение аутентифицированного состояния в OP, а не состояния истечения предоставленных областей RP.
Я также должен отметить, что это поведение одинаково, даже если пользователь никогда не входил в систему. Поэтому, если я захожу в приложение в новом окне инкогнито, я все еще наблюдаю redux-oidc/LOADING_USER, затем redux-oidc/USER_EXPIRED, поэтому я не могуопределить разницу между сеансом, который истек, и сеансом, который никогда не существовал.Если бы я мог сделать это различие, я мог бы по крайней мере инициировать свое собственное тихое обновление при запуске.
Так что я застрял здесь.Я предполагаю, что я либо что-то неправильно понял, либо реализовал что-то не так.Я решил начать с публикации здесь на случай, если проблема связана с самой redux-oidc или моей реализацией.Если вы думаете, что это больше касается моего понимания самого OIDC, я перейду к http://security.stackexchange.com.. Исследуя это, я также узнал о более широком разговоре о будущем потока implicit, в котором многие высказывались в пользуон устарел в пользу потока authorization_code.Я думаю, что это для другого вопроса, но подумал, что упомяну это в случае, если это уместно здесь.
Если вы прочитали это далеко, я ценю ваше время и заранее благодарю за любой совет.