Single sign-out and IdentityServer3
Single sign-out (or single logout, or SLO) is the mechanism by which a user is able to sign-out of all of the applications they signed into with single sign-on (SSO) including the identity provider. The OpenID Connect set of specifications contain three different specifications for how to handle single sign-out. Each provides a different approach to solve the problem based upon the nature of the application architecture that’s involved in the SSO process. The fact that there are three different approaches to dealing with the problem should be a hint that performing single sign-out is complex.
One, known as the “session management specification“, is targeted at JavaScript-based/SPA-style applications (and thus also known as the JavaScript-based sign-out spec). Another one, known as the “HTTP-based logout specification“, is targeted at server-side web frameworks (such as ASP.NET), and is also known as the “front-channel” approach. The last one, known as the “back-channel logout specification“, also targets server-side applications but takes a different approach than the “front-channel” spec. Each has their pros and cons.
Since its first release IdentityServer3 has supported the JavaScript-based “session management specification”, and as of build 2.2 from November of 2015 alsos implements the “front-channel” specification.
The JavaScript-based approach in essence requires a client application to load an <iframe> to an endpoint in IdentityServer called the “check_session_iframe” (whose value is available from the metadata endpoint). This <iframe> (given that it is from the IdentityServer’s origin) can access the session cookie managed by IdentityServer and can detect when the user’s login session has changed (meaning the user has signed out, or has signed in as another user). Once the user’s session has changed then the JavaScript-based application hosting the <iframe> can be notified that the user is no longer logged into IdentityServer. At that point, it’s up to the application to decide what to do, but at least it knows the user’s login status has changed.
The “front-channel” spec takes a different approach. It allows a client application to preregister a “logout URL” with IdentityServer. When the user signs out of IdentityServer, then on the “signed out” page of IdentityServer an <iframe> is then rendered into the page for each client application that has a registered “logout URL”. The request in the <iframe> allows the client application to receive a notification in the context of the user’s browser session that they are now logged out. In this request the client application can decide how to cleanup the user’s session and the most common approach would be to revoke the user’s session cookie at the client application.
You can read more about IdentityServer’s single sign-out support here.
brockallen 
Hi Brock, is there a way for a user who may have more than one app, the ability to force a sign-out of their first app? Say for example, I have a mobile app on a particular device and have logged and let’s say same user but now on a tablet (same app). Then the users loses their mobile device, can I setup an interface within IdentityServer to sign-out of that first app?
Logging out of mobile apps is a strange concept. You will want to invalidate tokens issued to that device/client, so use refresh tokens or reference tokens. Both can be invalidated using IdentityServer.
Hi Brock, I am currently analyzing a new native Mobile application for a client where we plan to expose the back-end API through a Managed API service such as APIgee. I am proposing to incorporate IndentityServer3 as an on premise STS. I am also reviewing other third party, paid solutions such as those from InAuth which have features such as Trusted Path, Application Validation, Deep Device Location Authentication,
Advanced Rooted/Jailbreak Check, Crimeware/Malware Detection, Asserted Identity,
Certificate Pinning and Secure Messaging and where some of these capabilities may make sense to implement. Would you happen to have a set of recommended resources (links/references) that provide alternatives to the above list that I could recommend when implementing along side of IdentityServer3? Some of the above mentioned capabilities are nice-to-have, not must-have and I would appreciate any insight that you could provide on which is in which camp along with an alternate path.
I don’t have a comparison sheet, sorry.
I implemented a ReactJs application using OIDC-Client, if I try to logout in one application its not logging out other tabs. I don’t know what I missed, Note: I’m using Identity Server 3
I don’t know either — you will have to debug it.
Hi Brock, you mentioned that “the “session management specification“, is targeted at JavaScript-based/SPA-style applications (and thus also known as the JavaScript-based sign-out spec) and the “HTTP-based logout specification“, is targeted at server-side web frameworks (such as ASP.NET), and is also known as the “front-channel” approach.” In the open id specifications I no where found such recommendations that which out of two approaches is meant for SPA style or Server based applications.
I was thinking that both the front channel and the session management approaches can be used by either SPA style or server based applications. Since for the front channel approach the Javascript based clients can expose their logout endpoint which can return the javascript code to clear any browser cookies and thus the Front Channel Implementations can be used by Javascript clients too.
Do you see any issues with this ?
You could use them for either scenario, yes, but I don’t see that as terribly practical. Front-channel wouldn’t work so well for JS apps because the “session” in a JS app normally is scoped to the window (typically via session storage). And a server-side app would need to have JS code detect the end session notification, and trigger a request to its own server to cleanup cookies. That’s why I made the comments I did.
Thanks for your valuable inputs from Brock!
Hi Brock, with sameSite cookie introduction in chrome, we are not able to host an application in iframe because identity server cookies are not marked with sameSite attribute None. Also, I am not seeing any options added in CookieOptions to pass this flag. Can you please guide how that can be achieved in identityServer 3?
https://leastprivilege.com/2020/01/05/identityserver3-and-upcoming-samesite-cookie-changes-in-browsers/
Thanks for the link Brock. It says identityServer 3 won’t have the support :( Can you recommend a way it can be done outside identityServer3 then? I tried setting in web.config file but it didn’t work for cookies generated by identity server? Any guidance will be helpful.