Skip to content

Single sign-out and IdentityServer3

February 8, 2016

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.

6 Comments leave one →
  1. John permalink
    April 12, 2016 10:48 am

    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?

    • April 13, 2016 8:03 pm

      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.

      • May 14, 2016 11:52 am

        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.

Trackbacks

  1. Federated sign-out and IdentityServer3 | brockallen
  2. Check session support in oidc-client-js | brockallen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: