What happened in 2018?

2018 has been really busy. We worked on a lot of different things, and I just realized that I only wrote eight blog posts in total.

I decided to block December to catch up on many work and non-work related things, work on a couple of “hobby” projects – and last but not least prepare for the holiday season (where I try to force myself to stay away from the computer – this time for real ;)

I thought I should write a final blog summarizing what we’ve been working and what kept us busy in the last 12 months.



PolicyServer is our commercial “authorization for modern applications” product that we announced at NDC in January this year. As you can imagine, this announcement required a lot of preparations and many things were very “last minute” – so much that the URL to the product was wrong on the slides when we made announcement (because we moved things around “last second”). Embarrassing.

But anyways – the feedback we got after the announcement was fantastic, and in the following weeks we got way more enquiries than we could handle. Ever since, this was our primary focus and we did a lot of customer work over the last 12 months to make sure that PolicyServer is really meeting the real world needs.

We have many plans for upcoming versions, and I must say it was a refreshing change to do some real product work as opposed to short to mid-term consulting and contracts. I also became “Mr. Devops” on our team (at least that’s how Brock likes to call me). Anyways – I figured out that automating “stuff” is actually fun.



This was also a big year for IdentityServer. We did tons of customer work around identity & access control, and it was very satisfying to see how good IdentityServer is at solving other people’s problems. While you can obviously always find things you would do differently today or would like to improve, the general design of IdentityServer has proven to be the right one. Some more facts:

  • we shipped three feature versions this year (2.1, 2.2 and 2.3) – and a couple of bug fix releases
  • 3 was a really big release and most notably – for the very first time a complete spec implementation was done as a contribution (meaning not from Brock or me). This spec is the so called “device flow” which allows devices without a browser or constrained input capabilities to connect to APIs using OAuth. Thanks Scott Brady!
  • As of today, IdentityServer has 153 contributors (thank you!), 3653 stars on Github and over 2,3 million downloads on Nuget.

We also started a Patreon page to allow companies to support IdentityServer, which in turn allows us to set more time aside from paid work.

As of today, we have 49 patrons – thank you all!! It is a bit surprising that most supportes are individual developers that use IdentityServer at work. I would have wished that more companies realize that it is important to back the OSS projects they rely on – let’s see what 2019 will bring.

Last but not least, the big news is, that the ASP.NET team decided to ship IdentityServer in their new templates that will be released shortly after v2.2. The integration comes with a simplified configuration system to target the specific template scenarios, but allows you to change over to the native configuration any time you want. I had to check my email archives, but this concludes a discussion we started with the ASP.NET team in 2012 (!)….

Btw – In case you wondered why we decided to strong name IdentityServer (and IdentityModel) – that’s ultimately the reason. It is required when you want to be part of an ASP.NET release. As part of that work, we also now Authenticode-sign our binaries as well as signed the Nuget packages.



The IdentityModel organization on Github is the home for our client libraries. The most popular one is IdentityModel itself with over 9,3 million downloads on Nuget.

IdentityModel has recently joined the .NET Foundation and has undergone the same treatment as IdentityServer (strong naming, Authenticode- and Nuget-signing). We also have proper docs now. I am currently working on a v4 which will have some breaking changes, but is a necessary clean-up for going forward.

Based on IdentityModel, there’s also OidcClient (a certified OpenID Connect client library for native clients) and AspNetCore.OAuth2Introspection (OAuth 2 introspection authentication handler for ASP.NET Core). Both get minor updates right now, and I am planning to release them all together beginning next year.

Brock is right now working on his JavaScript library called oidc-client.js to incorporate some of the latest security recommendations from the IETF. More on that in a separate post.

OK – that’s it. That’s pretty much how I split my work time. Of course there is also consulting and training and conferences – and it doesn’t really look like 2019 will be much quieter – and that’s a good thing!

See you next year!

Posted in .NET Security, ASP.NET Core, IdentityModel, IdentityServer, PolicyServer, Uncategorized | Leave a comment

Beware the combined authorize filter mechanics in ASP.NET Core 2.1


In ASP.NET Core 2.1 one of the security changes was related to how authorization filters work. In essence the filters are now combined, whereas previously they were not. This change in behavior is controlled via the AllowCombiningAuthorizeFilters on the MvcOptions, and also set with the new SetCompatabilityVersion API that you frequently see in the new templates.

Prior to 2.1 each authorization filter would run independently and all the authorization filters would need to succeed allow the user access to the action method. For example:

[Authorize(Roles = "role1", AuthenticationSchemes = "Cookie1")]
public class SecureController : Controller
    [Authorize(Roles = "role2", AuthenticationSchemes = "Cookie2")]
    public IActionResult Index()
        return View();

The above code would trigger the first authorization filter and run “Cookie1” authentication, set the HttpContext’s User property with the resultant ClaimsPrincipal, and then check the claims for a role called “role1”…

View original post 428 more words

Posted in Uncategorized | Leave a comment



In 2014 I developed and released the first version of IdentityManager. The intent was to provide a simple, self-contained administrative tool for managing users in your ASP.NET Identity or MembershipReboot identity databases. It targeted the Katana  framework, and it served its purpose.

But now that we’re in the era of ASP.NET Core and ASP.NET Identity 3 has come to supplant the prior identity frameworks, and it’s time to update IdentityManager for ASP.NET Core. Unfortunately I’ve been so busy with other projects I have not had time. Luckily Scott Brady, of Rock Solid Knowledge, has had the time! They have taken on stewardship of this project so it can continue to live on.

I’m happy to see they have released the first version of IdentityManager2. Here’s a post on getting started. Congrats!

View original post

Posted in Uncategorized | Leave a comment

Making the IdentityModel Client Libraries HttpClientFactory friendly

IdentityModel has a number of protocol client libraries, e.g. for requesting, refreshing, revoking and introspecting OAuth 2 tokens as well as a client and cache for the OpenID Connect discovery endpoint.

While they work fine, the style around libraries that use HTTP has changed a bit recently, e.g.:

  • the lifetime of the HttpClient is currently managed internally (including IDisposable). In the light of modern APIs like HttpClientFactory, this is an anti-pattern.
  • the main extensibility point is HttpMessageHandler – again the HttpClientFactory promotes a more composable way via DelegatingHandler.

While I could just add more constructor overloads that take an HttpClient, I decided to explore another route (all credits for this idea goes to @randompunter).

I reworked all the clients to be simply extensions methods for HttpClient. This allows you to new up your own client or get one from a factory. This gives you complete control over the lifetime and configuration of the client including handlers, default headers, base address, proxy settings etc. – e.g.:

public async Task<string> NoFactory()
    var client = new HttpClient();
    var response = await client.RequestClientCredentialsTokenAsync(new ClientCredentialsTokenRequest
        Address = "https://demo.identityserver.io/connect/token",
        ClientId = "client",
        ClientSecret = "secret"
    return response.AccessToken ?? response.Error;

If you want to throw in the client factory – you can register the client like this:


..and use it like this:

public async Task<string> Simple()
    var client = HttpClientFactory.CreateClient();
    var response = await client.RequestClientCredentialsTokenAsync(new ClientCredentialsTokenRequest
        Address = "https://demo.identityserver.io/connect/token",
        ClientId = "client",
        ClientSecret = "secret"
    return response.AccessToken ?? response.Error;

HttpClientFactory also supports named clients, which allows configuring certain things upfront, e.g. the base address:

    client => client.BaseAddress = new Uri("https://demo.identityserver.io/connect/token"));

Which means you don’t need to supply the address per request:

public async Task<string> WithAddress()
    var client = HttpClientFactory.CreateClient("token_client");
    var response = await client.RequestClientCredentialsTokenAsync(new ClientCredentialsTokenRequest
        ClientId = "client",
        ClientSecret = "secret"
    return response.AccessToken ?? response.Error;

You can also go one step further by creating a typed client, which exactly models the type of OAuth 2 requests you need to make in your application. You can mix that with the ASP.NET Core configuration model as well:

public class TokenClient
    public TokenClient(HttpClient client, IOptions<TokenClientOptions> options)
        Client = client;
        Options = options.Value;
    public HttpClient Client { get; }
    public TokenClientOptions Options { get; }
    public async Task<string> GetToken()
        var response = await Client.RequestClientCredentialsTokenAsync(new ClientCredentialsTokenRequest
            Address = Options.Address,
            ClientId = Options.ClientId,
            ClientSecret = Options.ClientSecret
        return response.AccessToken ?? response.Error;

..and register it like this:

services.Configure<TokenClientOptions>(options =>
    options.Address = "https://demo.identityserver.io/connect/token";
    options.ClientId = "client";
    options.ClientSecret = "secret";

…and use it e.g. like this:

public async Task<string> Typed([FromServicesTokenClient tokenClient)
    return await tokenClient.GetToken();

And one of my favourite features is the nice integration of the Polly library (and handlers in general) to give you extra features like retry logic:

    .AddTransientHttpErrorPolicy(builder => builder.WaitAndRetryAsync(new[]

This is work in progress right now, but it feels like this is a better abstraction level than the current client implementations. I am planning to release that soon – if you have any feedback, please leave a comment here or open an issue on github. Thanks!

Posted in ASP.NET Core, IdentityModel, Uncategorized, WebAPI | 6 Comments

Mixing UI and API Endpoints in ASP.NET Core 2.1 (aka Dynamic Scheme Selection)

Some people like to co-locate UI and API endpoints in the same application. I generally prefer to keep them separate, but I acknowledge that certain architecture styles make this conscious decision.

Server-side UIs typically use cookies for authentication (or a combination of cookies and OpenID Connect) and APIs should use access tokens – and you want to make sure that you are not accepting cookies in the API by accident.

Since authentication of incoming calls in ASP.NET.Core are abstracted by so called authentication handlers, and you can register as many of them as you want – you can support both authentication scenarios. That’s by design.

One way you could implement that is explicitly decorating every controller with an [Authorize] attribute and specify the name of the authentication scheme you want use. That’s a bit tedious, and also error prone. I prefer to have a global authorization policy that denies anonymous access and then rather opt-out of that with [AllowAnonymous] where needed.

This did not work prior to ASP.NET Core 2.1 because global policies rely on the default scheme configuration – but since we have two different schemes, there is no default. The effect would be e.g. that you would get a redirect to a login page for an anonymous API call where you would have expected a 401.

In ASP.NET Core 2.1 there is a new feature where you can dynamically select the authentication scheme based on the incoming HTTP request. Let’s say e.g. all your API endpoint are below /api – you could define a rule that for requests to that path you would use JWT tokens – and for all other, OpenID Connect with cookies. You do that by adding a forward selector to the authentication handler like this:

options.ForwardDefaultSelector = ctx =>
    if (ctx.Request.Path.StartsWithSegments("/api"))
        return "jwt";
        return "cookies";

For a full sample – see here.

Posted in ASP.NET Core, OpenID Connect, Uncategorized, WebAPI | 14 Comments

Improvements in Claim Mapping in the ASP.NET Core 2.1 OpenID Connect Handler

Here I described the various layers of claim mappings going on when doing OpenID Connect with ASP.NET Core.

Based on our feedback, the ASP.NET team added another mapping option to reduce the amount of “magic” going on, and thus makes it less confusing to get the expected claims in your client applications.

The new mapping is called MapAllExcept which does exactly what you think it does – it maps all the claims except the ones you don’t care about, e.g.:


This strips the protocol claims that you are not interested in, and all other claims get mapped forward (sample here). You still have to opt-out from the mapping to Microsoft proprietary claims – but well, we’ll get there eventually…

Posted in ASP.NET Core, OpenID Connect, Uncategorized | 2 Comments

The State of HttpClient and .NET Multi-Targeting

IdentityModel is a library that uses HttpClient internally – it should also run on all recent versions of the .NET Framework and .NET Core.

HttpClient is sometimes “built-in”, e.g. in the .NET Framework, and sometimes not, e.g. in .NET Core 1.x. So fundamentally there is a “GAC version” and a “Nuget version” of the same type.

We had lots of issues with this because it seemed regardless in which combination you are using the flavours of HttpClient, this will lead to a problem one way or another (github issues). The additional confusion was added by the fact that the .NET tooling had certain bugs in the past that needed workarounds that lead to other problems when those bugs were fixes in later tooling.

Long story short – every time I had to change the csproj file, it broke someone. The latest issue was related to Powershell and .NET 4.7.x (see here).

I once and for all wanted an official statement, how to deal with HttpClient – so I reached out to Immo (@terrajobst) over various channels. Turns out I was not alone with this problem.

Screenshot 2018-05-21 07.43.06

Despite him being on holidays during that time, he gave a really elaborate answer that contains both excellent background information and guidance.

I thought I should copy it here, so it becomes more search engine friendly and hopefully helps out other people that are in the same situation (original thread here).

“Alright, let me try to answer your question. It will probably have more detail than you need/asked for but I might be helpful to start with intention/goals and then the status quo. HttpClient started out as a NuGet package (out-of-band) and was added to the .NET Framework in 4.5 as well (in-box).

With .NET Core/.NET Standard we originally tried to model the .NET platform as a set of packages where being in-box vs. out-of-band no longer mattered. However, this was messier and more complicated than we anticipated.

As a result, we largely abandoned the idea of modeling the .NET platform as a NuGet graph with Core/Standard 2.0.

With .NET Core 2.0 and .NET Standard 2.0 you shouldn’t need to reference the SystemNetHttpClient NuGet package at all. It might get pulled from 1.x dependencies though.

Same goes for .NET Framework: if you target 4.5 and up, you should generally use the in-box version instead of the NuGet package. Again, you might end up pulling it in for .NET Standard 1.x and PCL dependencies, but code written directly against .NET Framework shouldn’t use it.

So why does the package still exist/why do we still update it? Simply because we want to make existing code work that took a dependency on it. However, as you discovered that isn’t smooth sailing on .NET Framework.

The intended model for the legacy package is: if you consume the package from .NET Framework 4.5+, .NET Core 2+, .NET Standard 2+ the package only forwards to the platform provided implementation as opposed to bring it’s own version.

That’s not what actually happens in all cases though: the HTTP Client package will (partially) replace in-box components on .NET Framework which happen to work for some customers and fails for others. Thus, we cannot easily fix the issue now.

On top of that we have the usual binding issues with the .NET Framework so this only really works well if you add binding redirects. Yay!

So, as a library author my recommendation is to avoid taking a dependency on this package and prefer the in-box versions in .NET Framework 4.5, .NET Core 2.0 and .NET Standard 2.0.

Thanks Immo!

Posted in IdentityModel, Uncategorized, WebAPI | 1 Comment