Skip to content

Process.Start for URLs on .NET Core

September 24, 2016

Apparently .NET Core is sort of broken when it comes to opening a URL via Process.Start. Normally you’d expect to do this:


And then the default system browser pops open and you’re good to go. But this open issue explains that this doesn’t work on .NET Core. So instead you have to do this (credit goes to Eric Mellino):

public static void OpenBrowser(string url)
        // hack because of this:
        if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
            url = url.Replace("&", "^&");
            Process.Start(new ProcessStartInfo("cmd", $"/c start {url}") { CreateNoWindow = true });
        else if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
            Process.Start("xdg-open", url);
        else if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
            Process.Start("open", url);

I added a few more fixes for Windows — one was suppressing the second command prompt, and another was escaping the “&” with “^&” so the shell does not treat them as command separators.

Fun times in this cross-platform world.


SDD Deep Dive, London 2016

September 13, 2016

In November 2016, Dominick and I will be speaking together at SDD Conf in London. We’re doing a 3-day version of our Identity & access control for modern web applications & API workshop which now targets ASP.NET Core and IdentityServer4.

The 3-day format allows much more time for hands-on labs, as well as in-depth discussions of how to architect for single sign-on and web API security. Also, we have extra time allotted to show how to customize and configure IdentityServer4.

Hope to see you there!


DEVintersection/IT Edge Las Vegas, October 2016

September 13, 2016

I’ll be speaking at DEVintersection/IT Edge in Las Vegas this October, 2016. I’m doing a 2-day workshop on Identity & Access Control for ASP.NET Core Applications and APIs which is targeting ASP.NET Core. I’m also doing a few sessions; one on mobile application security, one on JavaScript/SPA application security, and one on the new policy-based authorization system in ASP.NET Core.

Also, apparently there’s a promo code “ALLEN” you can use to get some money off the conference admission.

Hope to see you there!

Commercial Support Options for IdentityServer

August 16, 2016

Many customers have asked us for production support for IdentityServer. While this is sometime we would love to provide, Brock and I can’t do that on our own because we can’t guarantee the response times.

I am happy to announce that we have now partnered with our good friends at Rock Solid Knowledge to provide commercial support for IdentityServer!

RSK has excellent people with deep IdentityServer knowledge and Brock and I will help out as 2nd level support if needed.

Head over to and get in touch with them!

View original post

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.