3

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?

Dejan Janjušević
  • 3,181
  • 4
  • 41
  • 67
  • Why so complicated? Wouldn't be a lot of easier to use IdSrv4 with Opaque tokens (aka Reference Tokens) and just reduce (or if its a low traffic scenario: disable) the caching time? on a request, the service will ask the IdSrv's [revocation endpoint](http://docs.identityserver.io/en/release/endpoints/revocation.html) to see if the token is valid? – Tseng Sep 03 '18 at 08:27
  • @Tseng the revocation endpoint is only used for access and refresh tokens. I use cookies authentication with implicit flow. – Dejan Janjušević Sep 03 '18 at 08:38
  • why do you use backchannel with implicit flow? looks a bit strange. If you use cookies, it should be simpler to use front channel and revoke the cookies in iframes for all the clients involved. that's up to you to utilize both front- and back-, but afaik, back- implementation in IdSrv still relies on iframes in logout view, so it has no special props for (once again) implicit flow. – d_f Sep 06 '18 at 14:48
  • anyway, just following your scenario, I can't see any problem when your client A performs a "lazy signout" 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". – d_f Sep 06 '18 at 14:57
  • @d_f I wanted to use the front-channel sign out but I've encountered a situation where a client has IdentityServer hosted on https, while some of their clients on http. It's not allowed to create iframes from a secure web page which points to an insecure web page, which is why I decided to use the back-channel approach (the customer is always right, no?). Your second comment sounds good though, I DO trigger a cyclic single sign-out instead of just performing a challenge when lazily signing out. Can you post it as an answer, it sounds like a good one? – Dejan Janjušević Sep 06 '18 at 16:08
  • 1
    the customer is always right? maybe, maybe :) glad to help anyway! : ) – d_f Sep 06 '18 at 16:21
  • @TrimantraSoftwareSolution what have you tried? – Dejan Janjušević Oct 26 '18 at 06:30

1 Answers1

1

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".

d_f
  • 4,599
  • 2
  • 23
  • 34
  • Thanks, performing the challenge was the key. It makes sense actually, not sure why I triggered a new sign-out on lazy sign-out. A challenge would show the login page if the client was really signed out, and it would pick a new token and cookie if the client has meanwhile signed in. – Dejan Janjušević Sep 07 '18 at 09:54