Skip to content

Check session support in oidc-client-js

August 12, 2016

Single sign-out is a tricky business. For JavaScript-based applications OIDC provides the session management specification as a mechanism to be notified when the user has signed out or changed their login status at the OpenID Connect provider. It’s a somewhat confusing to read, and even more so to implement. For developers using IdentityServer, we always had samples for this which would help get this support into developers’ hands. But the samples were only that, samples.

Today I’m happy to announce that oidc-client-js (our OIDC/OAuth2 protocol library for browser-based JavaScript application) now supports the session management specification. This means one less piece of security plumbing you need to keep track of in your JavaScript-based applications.

Internally the UserManager will create the RP iframe necessary to poll the user’s session_state cookie. When the user’s status changes at the OP it will also attempt to silently re-query the OP to see if the user is still really signed in, or if they’re really signed out. Once it has determined that the user is really signed out of the OP, an event is raised letting your application know that the user has performed a signout. At this point, it’s up to your application to decide what to do. Here’s a snippet of registering for the event:

var settings = {
    authority: "https://localhost:44333/core",
    client_id: "js.usermanager",
    redirect_uri: "",
    response_type: "id_token token",
    scope: "openid profile email read write",
    silent_redirect_uri: ""
var mgr = new Oidc.UserManager(settings); () {
    log("user signed out");

Feel free to try it out (npm, github) and let us know how you like it. Thanks!

Demos — NDC Oslo 2016

June 9, 2016

Here are the demos from my ASP.NET Identity 3 session at NDC Oslo 2016.!1743&authkey=!AAhqMr8f6Y_o5to&ithint=folder%2czip

Looks like the recording is up too:


Don’t use TOTP for password resets

May 26, 2016

I saw a thread on the github issue tracker where someone was complaining that email verification and password reset tokens were too long in ASP.NET Identity 3. They are and I think this is a valid complaint because an end user can’t possibly type in the entire thing if necessary (for some reason line breaks are notorious in email readers and it always seems to happen to my sister in-law).

A suggestion was made on this thread to replace the normal data protection token generator with the TOTP (time based one-time password) generator so it would produce nice short 6 digit code. The problem with this is that an attacker can try to mount a brute force attack guessing all the possible codes within the validity window of the TOTP code (3 minutes in the ASP.NET Identity implementation). That means an attacker could try to guess all one million codes and they might get lucky in that much time. If they do, then they will be able to reset the password and pwn the account.

To properly mitigate against this, you need to do brute force protection on failed password reset requests. ASP.NET Identity does not do this for password reset requests (they do for login requests for both passwords and 2FA codes). I suppose they don’t perform this brute force check for password reset requests because the assumption is that they are using the default data protection mechanism which does mitigate this attack. So by default, ASP.NET Identity 3 is safe from this, but please don’t replace the plumbing without knowing what the consequences are.

Yea, security is hard.

oidc-client re-released

May 25, 2016

As part of building IdentityServer, we felt it was important to have lots of sample code to show how a developer can build client applications. And of course given the interoperability goal of OIDC, SPA-style JavaScript applications should be one of those samples.

When I started building our sample I found that there was no OIDC client JavaScript library out there (several OAuth2 ones, and vendor-specific ones, but not a pure OIDC protocol library). Of course, necessity is the mother of invention so I started working on one for our sample. This sample grew into a couple of ad-hoc libraries which were known as the OidcClient and TokenManger libraries. I even spoke about them at NDC last year.

Unfortunately, as samples tend to be turned into libraries on an as-needed basis, the organic nature of the evolution means that sometimes the code is not as well planned out and organized (or just not as pretty) as one would like it to be. I was called out for this several months ago, so with some corporate and community support I endeavored to re-write the library and clean it up using more modern techniques and tools.

Over the past 2 or 3 months I have rewritten the prior two libraries. They are now consolidated into one library, written in ES6, transpiled with babel, packed with webpack, built with gulp, and unit tested with mocha and chai. I feel pretty hip saying all those buzzwords in a single sentence, but I digress. In addition to the re-write, I’ve added a few more features and cleaned up existing ones.

So I’m quite happy to have released the rewritten and enhanced oidc-client this morning to npm. If you’re building a SPA style JavaScript application and need to handle authentication and calling secure web APIs using tokens from OIDC and OAuth2, try it out.

Feedback welcome. Enjoy.

Demos — SDD, May 2016

May 22, 2016

I did three sessions during SDD this past week in London. Here are the links to the slides/demos:!1733&authkey=!AO2jMkefQZQ-yhQ&ithint=folder%2czip

Thanks to the organizers and attendees!


Federated sign-out and IdentityServer3

February 9, 2016

The federation gateway pattern

Consider a scenario where you are building an application that requires the user to login from a variety of identity providers (IdPs). It is possible to implement the logic necessary to juggle the different IdPs from within a single application. But once you have more than one application with this same requirement it is undesirable to repeatedly re-implement this logic in each application.

This is where the “federation gateway” architectural pattern is commonly used. This involves using a token service in-between you applications and the IdPs being used. The logic of juggling the different IdPs is then consolidated in the gateway, and your applications are abstracted from these details.

IdentityServer3 can be (and frequently is) used in this capacity.

Below is a picture of the federation gateway pattern:


Federated sign-out

It’s not inconceivable that an IdP that’s being used has other applications relying upon it for authentication beyond your federation gateway. For example:


So what happens with a user of “Not Your App” logs out? Well, single sign-out can be done in many ways. Regardless of the approach, normally the user is redirected to the IdP to sign-out (“SalesForce” in the picture above). At this point, it would be quite useful for your gateway to know that this has occurred. Once your gateway knows the user has signed out of the IdP, the gateway can sign the user out, and then notify your applications to sign the user out as well.

This is all possible in IdentityServer3 as of build 2.2 released in November 2015, assuming the IdP being used supports a “front-channel” approach for single sign-out. Recall that a “front-channel” approach to sign-out creates an <iframe> to each of the client applications in the context of the user’s browser session, thus allowing the application to do any session related cleanup (such as revoking cookies).

To achieve this it is necessary for you to build an endpoint within the gateway that can act as the “cleanup endpoint” (which will be the target of the IdP’s <iframe>). This is something you must do manually, since you might be using different protocols to authenticate to the IdP (e.g. OIDC or WS-Fed). This endpoint would need to run within IdentityServer’s pipeline, meaning the URL must be one such that the IdentityServer middleware is allowed to execute. From that endpoint you would then use an OWIN environment extension API called ProcessFederatedSignoutAsync that we provide. This API performs the federated sign-out.

The “cleanup endpoint” might look some like this:

public void Configuration(this IAppBuilder app)
   app.Map("/core", coreApp =>
      var factory = new IdentityServerServiceFactory();

      // ...

      coreApp.Map("/signoutcleanup", cleanup =>
         cleanup.Run(async ctx =>
            await ctx.Environment.ProcessFederatedSignoutAsync();

Depending on the protocol used with the IdP you might need more logic in here, but the above code is all that’s needed to handle signing out from IdentityServer and to the applications using IdentityServer for authentication (assuming the applications themselves participate in single sign-out).

You can read more about the federated sign-out support in our docs.


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.