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

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.

IdentityServer

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.

IdentityModel

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!

I spent a lot of time on the client side recently – as part of our PolicyServer client libraries work, customer work, our updated guidance for our workshops as well as the various talks Brock and I gave on building clients for token-based systems (see here for a recording).

In particular for ASP.NET Core-based clients we’ve been going back and forth between various approaches, from completely manual to completely automated (see here) trying to find the best balance between control and convenience.

I think I’ve settled on an approach (at least for now) that integrates nicely with ASP.NET Core and gives you a couple of extensibility points to adjust to your environment (especially around token storage).

Which brings me to the 2nd part – now being sufficiently confident that this is the approach I want to (re-) use, how can I ship it as a library? IdentityModel deliberately has very few dependencies – so adding it there was not an option. Instead we decided to create a new project called IdentityModel.AspNetCore – and the idea is to extend IdentityModel for ASP.NET Core specific functionality and features. Feedback is as always very welcome.

OK – without further ado – how does the token management functionality work?

Basically all functionality is encapsulated in this line of code:

var token = await HttpContext.GetAccessTokenAsync();

This uses the same style as the built-in token storage APIs from Microsoft, but does a couple of things under the cover:

• It uses an extensible storage mechanism to retrieve the current access and refresh token. The default implementation will load the tokens from the authentication session in ASP.NET Core
• It will check the expiration of the access token, and if a configurable threshold is reached, refresh the access token (and also pass the refreshed tokens back to the storage abstraction)
• Return the access token back to the caller

You can now call this API from wherever you see fit, e.g. directly from the code where you make the outbound HTTP calls, or preferred (by me), from within a delegating handler that gets injected in your HTTP client via the factory.

Disclaimer: This is not a generic approach for refreshing tokens from arbitrary providers. The library makes the assumption that your primary OAuth 2 provider (the one that guards your APIs), is also OpenID Connect compliant (e.g. IdentityServer) and was used for authenticating the user. At least that’s how we built our applications – so it is bit opinionated.

The repo contains a sample that shows this approach. This is the very first version of this library – so please have a look and give me feedback if this would also work for you. Thanks!

IdentityModel has been growing organically over the last years, and we felt it is necessary to do some fundamental cleanup. At the same time it is used by a lot of people and companies (currently around 20 million downloads on nuget) – which is a bit scary when doing breaking changes.

But since we are at a point where a new .NET Core runtime is released, and thus many other libraries will release new major version, we thought that this might be a good opportunity to make the changes.

This version is a breaking release!!!

Stay on v3.x if you are using:

• IdentityServer4 v2.x
• IdentityServer4.AccessTokenValidation v2.x
• IdentityModel.AspNetCore.OAuth2Introspection v3.x
• IdentityModel.OidcClient v2.x

..in fact, I am in the process of pushing updates to these packages that sets an upper bound for the IdentityModel dependency (aka ‘[3.10.10,4.0)‘).

All subsequent major versions of the above mentioned packages have switched to IdentityModel v4 and will be released along with IdentityServer4 v3 on the 23rd September.

In the coming days I will push IdentityModel v4 to nuget – here’s a high level list of the changes.

Target frameworks
I dropped the net452 target – v4 is targeting net461 and netstandard2.0 only.

Removed old *Client classes
I removed the protocol client classes like TokenClient in favour of the newer style extension methods for HttpMessageInvoker (the base class of HttpClient).
I added a new TokenClient and IntrospectionClient based on the new design which is now DI and HttpClientFactory friendly. I did that mainly because I needed them in some other project. Give them a try, and see if they work for you as well.

Removed access token related delegating handlers for HttpClient
I never was happy with their design, and they also did not work for some common scenarios. Part of the work has been moved to OidcClient (for native apps) and part of it has been moved to the ASP.NET Core specific IdentityModel.

Updated extension methods
The protocol extensions methods have been re-written from the ground up. The public API surface stayed mostly the same, but certain classes have been renamed for clarity.
The request objects now derive from `HttpRequestMessage` which gives you more control over the HTTP details (e.g. headers).

Updated Epoch Extensions
Year 2038 is coming! All extensions have been updated to use long instead of int. Alternatively – .NET has built-in support now as well. So feel free to switch to that if you like.

Misc
I probably changed some parameter, classes and namespace names..

As I said, I will push v4 in the coming days. Now is your last chance to chime in if you feel something is wrong.

I just pushed Preview 3 of the 4.0 version of IdentityModel.OidcClient – this includes some major updates (that you might or might not have asked for):

• Removal of OpenID Connect Hybrid Flow.
  The codebase does Authorization Code Flow + PKCE only now. This is inline with RFC8525 and the AppAuth reference implementations. Also – this reduced the complexity of the codebase dramatically
• Support for pure OAuth-based request.
  Before this change, the openid scope was mandatory, which always meant OpenID Connect compliance on the server. You can now omit openid and do pure OAuth 2.0 as well.
• Removing JWT signature validation from the core codebase.
  The signature validation is now a pluggable component. I provide a default implementation using Microsoft’s JWT handler in a separate Nuget package. This allowed to remove that dependency from OidcClient.
• Removed dependency on NewtonSoft.Json
  Still IdentityModel uses it, this will change as well at some point.

All in all, this make OidcClient slimmer and thus hopefully easier to integrate into existing applications.

Please give it a try.