问题描述
编辑
Letz保持简单。
如何通过Windows身份验证在.Net Core 3.1应用程序中实现空闲超时？
为什么要使用Windows身份验证：因为在Windows（Active Directory）上进行身份验证时，我们无法注销。
空闲超时：：此功能表示屏幕空闲了一段时间（可以在IIS ->应用程序池->中进行配置，然后选择池->高级设置->空闲超时：（默认值：20分钟）），应用程序应注销并要求再次登录。或应该转到在startup.cs中设置的页面404
很高兴
- 使用Windows身份验证
- 尝试从IIS应用程序池中实现空闲超时。
- 在部署到IIS后，它也应该（也）可以工作。
当前行为
应用程序在空闲超时后关闭。
和
尝试浏览（单击任何链接），它将再次启动应用程序
尝试logout windows authentication但没有运气
预期的行为/输出
- 用于Windows身份验证的登录对话框弹出窗口
和/或
- 空闲超时后应达到404
解决方法
我认为您所要求的不是直接可能的，但您可能会接近。我不会在这里提供任何代码，因为这可能会很复杂，但是我希望它可以帮助您考虑问题。我同意@ jeremy-lakeman的观点，这是您正在寻找的“反特征”，也许您可以重新构建问题。
Windows身份验证
当服务器发回401时，Windows将通过kerberos自动进行身份验证。这对用户是透明的，并且没有登录页面。在您的情况下，这由IIS处理。使用Windows身份验证时，无论如何都不会显示登录页面。
Cookie身份验证
本质上，这是在用于验证用户身份的浏览器中存储cookie。 Asp.Net Core 3.1本身包含此功能，并且可以轻松地支持它。该cookie在应用程序级别进行身份验证。该cookie可以到期，并且您在页面中嵌入了一个登录表单。创建新项目时，这是“个人帐户”选项。
两者的混合体
想象一个世界，如下：
您有两个应用程序。您的主应用程序配置了Cookie身份验证（我们称其为“主”），而辅助应用程序配置为使用Windows身份验证（称为“辅助”）。您也可以想象使用IIS来执行此操作，并将Windows身份验证放在一个特定的路径上，但是将它作为两个独立的应用程序来考虑会更容易。
当您向Primary请求时，您的应用会验证Cookie。如果不存在任何cookie，或者它被拒绝（由于超时命中），您将被重定向（不是401未经授权，找到302）到Secondary，这只是Windows身份验证。它可以重新生成Cookie，然后将您发送回Primary。
但是，这不显示登录页面，我认为这是问题的症结所在。您要在同一应用程序中同时具有自动登录和手动登录功能。如果您具有自动登录功能，那么有效期有多长？他们将刷新并再次获得身份验证。
如果放弃自动登录（通过Windows身份验证）的想法，则只能使用一个具有Cookie身份验证的应用程序。
仅限Cookie
在这种情况下，您仅具有主设置，并且仅执行cookie身份验证。您可以具有一个针对Active Directory进行身份验证的身份提供程序。这是Windows Auth，但在应用程序级别，而不是IIS级别。
您将不得不在“自动登录”或“超时”之间进行选择。没有一个可以拥有两者的合理世界。