在ASP.NET Core 2上使用IdentityServer4,有两个与此用例相关的客户端,使用ASP.NET MVC5。
编辑:使用cookie进行身份验证,隐式流程。
使用如下的后端信道注销:
* 有4个应用程序涉及其中——两个客户端(称为客户端A和客户端B)、IdentityServer实例以及一个状态服务器来跟踪后端信道注销请求。
我遇到了以下问题:
当用户登录到客户端A,然后转到客户端B,然后在那里执行注销操作时,客户端B被注销,但是直到下一个针对客户端A的请求被发出后,客户端A才被注销。因此,如果用户现在决定使用另一个账户(或相同的账户,无论如何),然后只转到客户端A,客户端A将发起注销,因为状态服务器上有一个未处理的注销请求,而忽略了用户在此期间重新登录的事实。
有没有人有什么想法可以防止这种情况发生?
编辑:使用cookie进行身份验证,隐式流程。
使用如下的后端信道注销:
* 有4个应用程序涉及其中——两个客户端(称为客户端A和客户端B)、IdentityServer实例以及一个状态服务器来跟踪后端信道注销请求。
- 客户端A开始注销,使登录cookie无效。
- 客户端A用户被重定向到IdentityServer的/account/logout,并带有正确的id_token。
- IdentityServer使登录cookie无效并调用所有已签入客户端的后端信道注销操作。
- 客户端B的后端信道注销操作验证请求并通知状态服务器注销请求。
- 当发出向客户端B的下一个请求时,该客户端查询状态服务器并获取有关未处理注销请求的信息,这导致它使注销cookie无效,从而成功地注销登录。
sub
和sid
声明。我遇到了以下问题:
当用户登录到客户端A,然后转到客户端B,然后在那里执行注销操作时,客户端B被注销,但是直到下一个针对客户端A的请求被发出后,客户端A才被注销。因此,如果用户现在决定使用另一个账户(或相同的账户,无论如何),然后只转到客户端A,客户端A将发起注销,因为状态服务器上有一个未处理的注销请求,而忽略了用户在此期间重新登录的事实。
有没有人有什么想法可以防止这种情况发生?