Asp.net 如何跨客户端应用程序和Identityserver4处理空闲会话超时

我陷入困境，需要一些建议或解决办法。对于我们的单点登录实现，我有一个相当简单的IdentityServer4设置

三个应用程序

具有asp.net核心标识（ID服务器）的IdentityServer 4

ASP.NET Core 2.2 MVC（客户端1）

ASP.NET Core 2.2 MVC（客户端2） MVC客户端是使用混合授权设置的

两种情况：

如果用户在任何一个客户端（例如client1）中处于活动状态，则在该应用（client2）中达到空闲超时后，用户不应在client2中注销

如果用户在两个客户端（client1和client2）中都处于非活动状态，则当空闲超时超过时，系统应将用户从所有客户端（client1和client2）注销

场景1：用户在任何一个客户端中处于活动状态。 用户在客户端1中处于活动状态，在客户端2中处于空闲状态 预期行为： 当空闲超时超过时，系统不应从client2注销。 当前身份行为： 能够在client1中继续工作，但client2和ID服务器在空闲时间超过后导航到登录页面

情景2： 用户在所有2个客户端（客户端1和客户端2）中处于非活动状态 预期行为： 当空闲超时超过时，系统应从所有2个客户端和ID服务器注销用户

如果我仅在ID server中设置cookie过期时间（removed SlidingExpire为true，并且client1和client2中的cookie过期时间均为true），则客户端应用程序在没有过期时间的情况下连续工作，即使在ID server过期时间超过之前，这两个客户端都处于空闲状态，客户端应用程序仍在连续工作

我想知道是否可以实现预期的行为

客户：

 .AddCookie(options =>
                {
                    // Configure the client application to use sliding sessions
                    options.SlidingExpiration = true;
                    // Expire the session of 15 minutes of inactivity
                    options.ExpireTimeSpan = TimeSpan.FromMinutes(15);
                })

ID服务器：

services.AddIdentityServer(options =>
            {
                options.Authentication.CookieLifetime = TimeSpan.FromMinutes(15);
                options.Authentication.CookieSlidingExpiration = true;
            })

---

首先需要回答的问题是：什么系统，在哪里

浏览器客户端不可信任，不应干扰。我认为最好恢复cookie设置。不要让前端尝试触发注销

最好在后端跟踪用户。您可以通过在Mvc客户机中添加一个服务来实现这一点，该服务为1。通过IdentityServer 2将用户注册为活动用户。跟踪活动和3。当用户看起来不活动的时间过长时，通过IdentityServer注销该用户。查看IdentityServer附带的服务，了解如何使用间隔更新列表

在启动两个Mvc客户端时，为cookie添加一个处理程序：

Services
    .AddAuthentication(options =>
    {
        options.DefaultScheme = "Cookies";
        options.DefaultChallengeScheme = "oidc";
    })
    .AddCookie("Cookies", options =>
    {
        // you'll need to create your own handler
        options.EventsType = typeof(MyCookieEventHandler);
    })

我不会在这里添加代码，而是解释其目的：每当用户需要访问安全源时，都会调用cookiehandler。这意味着您可以在此处更新用户活动时间戳（用于跟踪用户），这意味着您不必一直联系IdentityServer。只有在状态发生更改时，服务才应联系IdentityServer：用户已变为活动或非活动状态

现在，您需要向IdentityServer添加一个服务，以便在中心位置跟踪用户。您可以在存储中保留用户的状态。当用户处于活动状态时添加用户（每个客户端），当用户不再处于活动状态时删除该用户。当用户的最后一个会话从此列表中删除时，触发

反向通道注销可以向mvc客户端发出用户已注销的信号。然后使用CookieEventHandler拒绝用户访问。这不会在注销时更新前端，但在用户联系mvc客户端时有效。它将发现自己从所有应用程序和Identityserver中注销

---

当您点击链接时，您将看到CookieEventHandler的一个实现。在互联网上搜索反向通道注销，您可能会找到您可以使用的示例。

我们采取的方法，我认为符合OIDC规范精神的方法是，IDP会话是主会话，可以长期使用。IDP不关心客户端会话，但客户端应监控IDP会话（会话监控规范），当IDP注销时，客户端会话也应注销（前端或后端通道）。从客户端显式注销也应注销您的IDP会话

此外，由于协议支持

prompt=login

和

max_age=n

，因此即使IDP上已经存在活动会话，您也可以强制执行交互式身份验证。这允许客户端实施其自己的策略，以确定用户必须进行身份验证的频率-例如，要访问管理功能，您必须在过去5分钟内或类似时间内进行身份验证

---

如果会话监视在IDP auth cookie过期时启动，但在IDS4中不会出现这种情况，那么这也很好。但是，应该可以创建一个自定义IUserSession实现，使会话ID cookie与主身份验证cookie正确对齐

几个问题1。我是否必须删除Options.Authentication.CookieLifetime=TimeSpan.FromMinutes（15）；options.Authentication.CookieSlidingExpiration=true；在IdentityServer中？2.只有在状态发生更改时，服务才应联系IdentityServer：用户已变为活动或非活动状态。-MVC中的服务如何联系IdentityServer？3.当用户的最后一个会话从此列表中删除时-我需要在何时何地查看此列表？1。我不知道默认值，但您可以使用长寿命cookie，因为CookieEventHandler现在负责cookie的生存期。2.使用新端点扩展Ids4，您可以在其中更新状态，例如使用httpclient。3.创建一个新表（用于ids4），在其中存储用户/客户端时间戳。客户端更新状态，而清理服务删除超过时间戳的所有条目。一旦最后一条记录（由ids4/客户端）从存储中删除，通过通知所有活动客户端（通过Usersession可用）执行完全注销。这有帮助吗？嗯，这是有道理的。但这里的问题是，如果用户登录到不同的浏览器（chrome/firefox）