IdentityServer for ASP.NET Core 3

In short: is released (along with the introspection and access control validation handler).

As part of the longer version, you might ask yourself how we can do that before ASP.NET Core 3 itself is released. Well – it’s a slightly complicated story.

Since the IdentityServer Nuget packages are referenced in some of the ASP.NET Core 3 templates, we had a bit of a chicken/egg situation, and we worked closely with the ASP.NET Team (thanks Javier!) to make sure we are doing this right.

Our 3.0 version is referencing ASP.NET Core 3 Preview9 which is fully supported for production and we were promised that there won’t be any changes that affect us between now and their RTM. IOW – ASP.NET Core 3 will ship with a reference to our 3.0 – and on the 23rd September, we will release a 3.0.1 which then will in turn reference their 3.0…and hopefully all the stars align ;)

(For those who know – this concludes a long – and sometimes painful – journey, that started back in 2012)

Long story short – our version of IdentityServer4 targeting ASP.NET Core 3 is now on Nuget, and you can give it a try. Next step for us is updating all our docs, samples and workshop materials, which should be done by the 23rd September.

What’s new?
Well not a lot really. Our main focus was to ensure compatibility with ASP.NET Core 3, but since we had the opportunity to do a bit of a re-org, we added the last missing pieces that were required for our FAPI compliance. Namely support for the PS* family of signing algorithms (along with support for elliptic curves as well) and s_hash support. More details in upcoming blog posts.

As always – feedback is appreciated.

repo / commits / release notes

Posted in ASP.NET Core, IdentityServer, Uncategorized | 4 Comments

Releasing IdentityModel v4

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 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.

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.

Posted in IdentityModel, Uncategorized | Leave a comment

Claims-based Identity & Access Control for .NET, ASP.NET and WCF 4.5 now retired on PluralSight

Time flies!

I just got notice from PluralSight that the above mentioned three courses are now retired and are not included in search results anymore. If you still care about this content – the direct links still work, and here they are:

Introduction to Claims-based Identity & Access Control

Claims-based Identity & Access Control in ASP.NET 4.5

Claims-based Identity & Access Control in WCF 4.5


Posted in .NET Security, ASP.NET, Uncategorized, WCF | Leave a comment

End of IdentityServer3 free Support

Back in 2017 we announced the end of IdentityServer3 maintenance. This excluded security bug fixes.

As of the 1st of July 2019 Microsoft officially ended support for Katana 3. This means that the platform we originally built-against is now unsupported and we completely stop supporting IdentityServer3 (including security bugs) for free now as well.

If you are still running IdentityServer3, you can get commercial support from us to further receive security notifications and updates and support in general. Or we can help you upgrading to ASP.NET Core and IdentityServer4. Contact us.

Posted in IdentityServer, Katana, Uncategorized | 1 Comment

Another Take on Access Token Management in ASP.NET Core (…and announcing IdentityModel.AspNetCore)

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.

Remark: IdentityServer (and maybe other token services) has a feature to allow a refresh token to be used only once (the RefreshTokenUsage property on the Client). This feature is designed for public clients like native apps and not so much for confidential clients like ASP.NET Core web applications. It also gets in the way with token management like described above. If your token management code gets executed (almost) at the same time but e.g. on different nodes, some nodes will get an error during refresh because the refresh token has been used more than once. You should not use this option in this scenario.

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!

Posted in ASP.NET Core, IdentityModel, OAuth, OpenID Connect, Uncategorized | Leave a comment

IdentityServer4 Roadmap

We didn’t have a lot of time recently to work on IdentityServer4 – and yes, I know there are a lot of open “backlog” issues right now. But fortunately everything is pretty stable and from the open issues, nothing seems to be really a show stopper. If we can’t get back quick enough, it’s mainly because we have to balance our time between OSS and paid work to make it work for everyone. If you think we are not getting back on an issue you opened, feel free to remind us.

Just a quick re-cap what happened recently.

2.3 – we added support for the “Device Authorization Grant” – this spec will go final soon!

2.4 – we added support the current draft of the “Mutual TLS” spec. This was sponsored work, and we are happy we finally have that feature built-in. Working on docs now.

2.5 – will be released fairly soon and will include another sponsored feature I wanted to have for a long time. More details soon.

After 2.5 we will finally get to the “small bugs” – so expect a 2.5.x pretty soon after that.

Then you might have heard that ASP.NET Core 3 Preview3 shipped with the long awaited templates including IdentityServer integration (docs here). This uncovered some problems going forward. Since the current IdentityServer is built against the 2.1 ASP.NET Core runtime, there will be incompatibilities with 3.0 (see e.g. here).

This means that we need to start now to also build against the new v3 bits and the first preview is already on nuget. This doesn’t make things easier…If you find any issues with our previews and ASP.NET Core 3, please let us know!

There will be a 3.0 of IdentityServer4 built against ASP.NET Core 3. This release will probably not have any major updates or new features, but tries to make sure we are not hit by any breaking changes in ASP.NET.

Since ASP.NET Core 3.0 will not be an LTS release, we will pretty soon after our 3.0 start working on a 4.0 targeting ASP.NET Core 3.1 which will be the new LTS. This version will have major feature updates. Confusing? Yes.

IOW – we will need to maintain three branches of IdentityServer soon: 2.x for ASP.NET Core 2.1, 3.x for ASP.NET Core 3.0 and 4.x for ASP.NET Core 3.1. Yay.

This also led to a major re-structuring of our repos. We merged the core IdentityServer repos into a mono repo, updated the build automation and moved to a simpler branching strategy.

Please keep that in mind if we don’t immediately respond to your questions ;)

Posted in IdentityServer, Uncategorized | Leave a comment

Try Device Flow with IdentityServer4

The biggest new feature in IdentityServer4 v2.3 is support for the beta Device Flow specification.

Device Flow is a flavour of OAuth 2.0 optimised for browserless and/or input-constrained devices. Things like TVs, gaming consoles, printers, cash registers, audio appliances etc. come to mind here.

The flow works like this:

  1. The client does a so called “device authorization request”. This returns both a device code and a user code.
  2. The client typically shows a URL to the user that includes the user code, e.g. The client might also show a QR code for that URL, to make that process even simpler.
  3. The user is now supposed to go to this URL on a separate device, e.g. a laptop computer or a phone/tablet. There the user will authenticate and consent. While this is happening, the client polls the token endpoint with the device code to find out when this part is done.
  4. Once the interactive part is done, the token endpoint will return the typical OAuth tokens like access and refresh token.
  5. Done

Or, if you think a picture says more than 1000 words – here’s the ASCII art from the RFC:

Screenshot 2019-02-08 13.03.06.png

You can try Device Flow with our demo instance of IdentityServer4 – and here is a fully functional client/api sample to go along with it.


Posted in ASP.NET Core, IdentityServer, OAuth | Leave a comment

An alternative way to secure SPAs (with ASP.NET Core, OpenID Connect, OAuth 2.0 and ProxyKit)

You might have noticed the recent public discussions around how to securely build SPAs – and especially about the “weak security properties” of the OAuth 2.0 Implicit Flow. Brock has written up a good summary here.

The whole implicit vs code flow discussion isn’t particularly new – and my stance was always that, yes – getting rid of the tokens on the URL is nice – but the main problem isn’t how the tokens are transported to the browser, but rather how they are stored in the browser afterwards.

Actually, we had this discussion already back in May 2015 on the OAuth 2.0 email list, e.g.:

My conjecture is that it does not matter >>at all<< where you store tokens in relation to XSS. There is no secure place to store data in a browser in ways that cannot be abused by XSS. One XSS is complete compromise of the client.

And XSS resistant apps are illusive.

Jim Manico – here

What about CSP?

Content Security Policy was created to mitigate XSS attacks in the browser. But to be honest, I see it rarely being used because it is hard to retro-fit into an existing application and interferes with some of the libraries that are being used. Even in brand new applications it is often an afterthought, and the longer you wait, the harder it becomes to enable it.

And btw – getting CSP right might be harder than you think – check out this video about bypassing CSP.

Screenshot 2019-01-18 08.38.39.png

In addition, JS front-end developers typically use highly complex frameworks these days where they do not only need to know the basics of JavaScript/browser security, but also the framework specific features, quirks and vulnerabilities. Let alone the quality of known and unknown dependencies pulled into those applications.

Oh and btw – the fact that the new guidance around SPAs and Authorization Code Flow potentially allows refresh tokens in the browser, the token storage problem becomes even more interesting. the conclusion turned out to be:

SPA may turn out to be impossible to completely secure.

John Bradley – here

Just like there is IETF guidance for native apps, we always thought there should be a similar document that talks about SPAs. But it seemed everyone was trying to avoid this.

Finally, the work on such a document has started now, and you can track it here.

What about Token Binding?

For me, the most promising technology to protect tokens stored in the browser was token binding (and especially the OAuth 2.0/OpenID Connect extensions for it). This would have allowed to tie the tokens to a browser/TLS connection, and even if an attack would be able to exfiltrate the tokens, it could not be used outside the context of this original connection.

Unfortunately, Google decided against implementing token binding, and if the standard is not implemented in all browsers, it’s pretty much useless.

What other options do we have?

The above mentioned IETF document mentions two alternative architecture styles that result in no access tokens at all in the browser. Let’s have a look.

Screenshot 2019-01-17 17.57.42.png

Apps Served from the Same Domain as the API

Quoting 6.1

For simple system architectures, such as when the JavaScript application is served from the same domain as the API (resource server) being accessed, it is likely a better decision to avoid using OAuth entirely, and just use session authentication to communicate with the API.

Some notes about this:

  • This is indeed a very simple scenario. Most applications I review also use APIs from other domains, or need to share their APIs between multiple clients (see next section).
  • This is also not new. Especially “legacy” application often had local “API endpoints” to support the AJAX calls they sprinkled over their “multi-pages” over the years.
  • When traditional session authentication (aka cookies) is used, you need to protect against CSRF. Implementing anti-forgery for APIs is extra work, and while well-understood I often found it missing when doing code reviews.

The new kid on the block: SameSite cookies

SameSite cookie are a relatively new (but standardised) feature that prohibits cross-origin usage of cookies – and thus effectively stops CSRF attacks (well at least for cookies – but that’s what we care about here). As you can see, it is implemented in all current major browsers:

Screenshot 2019-01-18 09.33.49.png

ASP.NET Core by default sets the SameSite mode to Lax – which means that cross-origin POSTs don’t send a cookie anymore – but GETs do (which pretty much resembles that standard anti-forgery approach in MVC). You can also set the mode to Strict – which also would prohibit GETs.

This can act as a replacement for anti-forgery protection, but is relatively new. So you decide.

Bringing it together

OK – so let’s create a POC for this scenario, the building blocks are:

  • ASP.NET Core on the server side for authentication and session management as well as servicing our static content
  • Local or OpenID Connect authentication handled on the server-side
  • Cookies with HttpOnly and Lax or Strict SameSite mode for session management (see Brock’s blog post on how to enable Strict for remote authentication)
  • ASP.NET Core Web APIs as a private back-end for the SPA front-end

That’s it. This way all authentication is happening on the server, session management is done via a SameSite cookie that is not reachable from JavaScript, and since there are no tokens stored in the browser, all the client-side APIs calls don’t need to deal with tokens or token lifetime management.

The full solution can be found here.

Browser-Based App with a Backend Component

Quoting 6.2.:

To avoid the risks inherent in handling OAuth access tokens from a purely browser-based application, implementations may wish to move the authorization code exchange and handling of access and refresh tokens into a backend component.

The backend component essentially becomes a new authorization server for the code running in the browser, issuing its own tokens (e.g. a session cookie).  Security of the connection between code running in the browser and this backend component is assumed to utilize browser-level protection mechanisms.

In this scenario, the backend component may be a confidential client which is issued its own client secret.

This is a much more common scenario and some people call that a BFF architecture (back-end for front-end). In this scenario, there is a dedicated back-end for the SPA that provides the necessary API endpoints. These endpoints might have a local implementation or in turn contact other APIs to get the job done. These other APIs might be shared with other front-ends and might also require a user-context – IOW the BFF must delegate the user’s identity.

The good news is, that technically this is a really easy extension to the previous scenario. Since we already used OpenID Connect to authenticate the user, we simply ask for an additional access token to be able to communicate with the shared APIs from the back-end.

The ASP.NET Core authentication session management will store the access token in an encrypted and signed cookie and all token lifetime management can be automated by plugging-in the component I described in my last blog post. This allows the BFF to use the access token to call back-end APIs on behalf of the logged-on user.

One thing I noticed is, that you often end up duplicating the back-end API endpoints in the BFF to make them available to the front-end, which is a bit tedious. If all you want is passing through the API calls from the BFF to the back-end while attaching that precious access token on the way, you might want to use a light-weight reverse proxy: enter ProxyKit.

A toolkit to create HTTP proxies hosted in ASP.NET Core as middleware. This allows focused code-first proxies that can be embedded in existing ASP.NET Core applications or deployed as a standalone server.

While ProxyKit is very powerful and has plenty of powerful features like e.g. load balancing, I use it for a very simple case: If a request comes in via a certain route (e.g. /api), proxy that request to a back-end API while attaching the current access token. Job done.

app.Map("/api", api =>
    api.RunProxy(async context =>
        var forwardContext = context.ForwardTo("http://localhost:5001");
        var token = await context.GetTokenAsync("access_token");
        forwardContext.UpstreamRequest.Headers.Add("Authorization""Bearer " + token);
        return await forwardContext.Execute();

I think it is compelling, that combining server-side OpenID Connect, SameSite, automatic token management and ProxyKit, your SPA can focus on the actual functionality and is not cluttered with login logic, session and token management. And since no access tokens are stored in the browser itself, we mitigated at least this specific XSS problem.

Again, the full sample can be found here.

Some closing thoughts

Of course, this is not the silver-bullet. XSS can still be used to attack your front- and back-end.

Screenshot 2019-01-17 17.58.23.png

But it is a different threat-model, and this might be easier for you to handle.

Also you are doubling the number of round-trips and you might not find this very efficient. Also keep in mind that if you are using the reverse-proxy mechanism you are not really lowering the attack surface of your back-end APIs.

But regardless if you are using OAuth 2.0 in the browser directly or the BFF approach, XSS is still the main problem.


This article was quoted or questioned like “this approach is better than tokens”. This was not the point and I apologize if I wasn’t clear enough. It is an alternative approach to the “pure” OAuth 2 approach – and I am not saying it is better or worse. Both approaches have a different threat model and you might be more comfortable with one or the other.

Maybe you also need to evaluate your architecture based on the fact where the APIs live that you want to call. Would you bother with OAuth if all APIs are same-domain? Where is the tipping point? If all APIs are cross-domain then it certainly is questionable if they should proxied.

Anyways – time will tell and SameSite cookies are still very new but certainly give you a new interesting option.

Posted in ASP.NET Core, OAuth, OpenID Connect, WebAPI | 15 Comments

Automatic OAuth 2.0 Token Management in ASP.NET Core

As part of the recent discussions around how to build clients for OpenID Connect and OAuth 2.0 based systems (see e.g. Brock’s post here), we substantially updated our workshop and supporting libraries. The updated material (both workshop and break-out sessions) will be part of the upcoming conferences (Oslo, London, Porto, Copenhagen…).

One piece of the puzzle is how to manage OAuth 2.0 access tokens in ASP.NET Core server-side (e.g. MVC) web applications (another piece can be found here – more details soon.

In a nutshell, a client for a token-based system has these fundamental jobs:

  1. Request the token
  2. Use the token

Easy right? Well – there is one step missing (which is actually the most complicated): manage the token.

Looking a bit closer, the actual tasks are:

  1. Use OpenID Connect to authenticate a user and start/join a (single sign-on) session. This will result in an identity token that is used to validate the authentication process
  2. This identity token must be stored somewhere to do a clean sign-out at some later point
  3. As part of that you also request an access and refresh token to be able to communicate with APIs on behalf of the logged-on user
  4. These tokens must be also stored somewhere secure so that the application code can use them when doing API calls
  5. When the access token expires, use the refresh token to request a new access token and make this new token available to application code
  6. At sign-out time, use the identity token to authenticate the sign-out request, and revoke the tokens that you don’t need anymore (e.g. the refresh token)
  7. Make it work in a web farm

While you can build all of that from scratch – let’s have a look at what ASP.NET Core has built-in to assist you.

OpenID Connect Authentication Handler

The OIDC support in ASP.NET Core is pretty full featured. It supports Implicit Flow for authentication only scenarios and the more secure Hybrid Flow (aka code id_token) for authentication and access/refresh token requests. It would be nice if it would also support “Code + PKCE” out of the box, but that’s a topic for another post.

Most importantly, the handler has the concept of persisting the tokens into the authentication session. IOW – it makes the OIDC artefacts like identity, access and refresh token available to application or plumbing code.

If the identity token is available in the authentication session, it will be automatically used as a hint at sign-out time to authenticate the sign-out request to the identity provider.

The Authentication Session

ASP.NET Core has the concept of an authentication session. Even if they put that behind a whole lot of abstraction APIs, for all practical purposes, this is technically implemented by the cookie authentication handler – and – well a cookie.

Don’t confuse that with the more general session concept – the authentication session is solely for identity/security related information like claims, tokens, expiration times etc.

If you set the SaveTokens options on the OpenID Connect handler to true, the handler will persist the tokens and corresponding metadata in the session. You can then later access them via the GetTokens extension method on HttpContext, or by directly calling AuthenticateAsync on the name of the sign-in scheme. This returns an AuthenticateResult, which again has a properties dictionary containing the tokens.

Technically speaking the tokens are serialized into the authentication cookie, at least by default. You might not like that, because it potentially increases the size of your cookie substantially. Another good reason to keep those tokens small.

Another option is to plug in a server-side storage mechanism, e.g. Redis. This way all the data is stored server-side, associated with a GUID – and also the GUID is emitted into the cookie. For that you need an ITicketStore implementation and set that on the SessionStore property on the cookie handler options.

The cookie handler also has support for events, e.g. whenever a cookie is received, or when sign-out is happening. This is a convenient place to wire up automatic token management, e.g.

  • On every incoming request, check the expiration time of the current access token, and if a certain threshold is reached, use the refresh token to get a new access token
  • At sign-out time, call the revocation endpoint at the token service to revoke the refresh token

With that in place you can implement all necessary token management features at the runtime level, and your application code is completely unaware of these details. It simply uses the current access token from the authentication session. If an API call returns a 401, this means that the token management layer was not able to keep the token “fresh” and manual steps (e.g. a new authentication request) is necessary.

Sounds a bit abstract? Find a working sample here

Some key points about the sample:

  • All the cookie events are handled in a dedicated class which gets instantiated using the DI system
    • the ValidatePrincipal method is called on every request and contains the refresh logic
    • the SigningOut method is called at sign-out time to do the token revocation (for both self-initiated sign-outs as well as sign-out notifications).
  • All the OAuth protocol work is done by IdentityModel and is just a matter of calling some extensions methods on an HttpClient retrieved from the HttpClientFactory
  • Using some ASP.NET config black magic, you can condense the whole thing to one line of code .AddAutomaticTokenManagement (yay)



Posted in ASP.NET Core, Uncategorized | 10 Comments

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