Search code examples
asp.netauthenticationasp.net-coreidentityserver4openid-connect

IdentityServer4 back-channel logout problem


Using IdentityServer4 on ASP.NET Core 2. Two clients relevant for this use case using ASP.NET MVC5.

EDIT: Using cookies for authentication, implicit flow.

Using the back-channel sign out like this:
* There are 4 applications involved - two clients (let's called them client A and client B), IdentityServer instance, and a state server to keep track of back-channel sign out requests.

  1. Client A initiates the sign out, invalidates the sign-in cookie.
  2. Client A user gets redirected to IdentityServer's /account/logout with a correct id_token.
  3. IdentityServer invalidates the sign-in cookie and calls back-channel sign out actions for all signed-in clients.
  4. Back-channel sign out action of client B validate the request and notify the state server of the log-out request.
  5. When the next request towards the client B is made, that client queries the state server and obtains information about an outstanding sign out request, which causes it to invalidate the sign-out cookie, thus resulting in successful sign out.

The state server keeps track of the two parameters: sub and sid claims from id_token.

I am having the following problem:

When users sign in to a client A, then navigate to the client B and then perform the sign out there, client B is signed out, but client A not until the next request towards it is made. So if users now decide to sign in to client B with another (or the same, doesn't matter) account and only then navigate to client A, client A will initiate the sign out because there was an outstanding sign out request waiting on the state server, disregarding the fact that users have signed in again in the meantime.

Does anyone have an idea on how to prevent this?


Solution

  • Following your scenario, I can't see any problem when your client A performs a "lazy sign-out" which triggers a new challenge to IdSrv, finishing with a new token and a new cookie.
    The main point should be not to trigger a (cyclic) single sign-out on each particular "lazy sign out".