Wow – this was probably our biggest update ever! Version 2.0 of IdentityServer4 is not only incorporating all the feedback we got over the last year, it also includes the necessary updates for ASP.NET Core 2 – and also has a couple of brand new features. See the release notes for a complete list as well as links to issues and PRs.
The highlights (from my POV) are:
ASP.NET Core 2 support
The authentication system in ASP.NET Core 1.x was a left-over from Katana and was designed around the fact that no DI system exists. We suggested to Microsoft that this should be updated the next time they have the “luxury” of breaking changes. That’s what happened (see more details here).
This was by far the biggest change in IdentityServer (both from a config and internal plumbing point of view). The new system is superior, but this was a lot of work!
Support for the back-channel logout specification
In addition to the JS/session management spec and front-channel logout spec – we also implemented the back-channel spec. This is for situations where the iframe logout approach for server-side apps is either too brittle or just not possible.
Making federation scenarios more robust
Federation with external providers is a complex topic – both sign-in and sign-out require a lot state management and attention to details.
The main issue was the state keeping when making round–trips to upstream providers. The way the Microsoft handlers implement that is by adding the protected state on the URL. This lead to problems with URL length (either because Azure services default to 2KB of allowed URL length, e.g. Azure AD or because of IE who has the same restriction). We fixed that by including a state cache that you can selectively enable on the external handlers. This way the temporary state is kept in a cache and the URLs stay short.
Internal cleanup and refactoring
We did a lot of cleanup internally – some are breaking changes. Generally speaking we opened up more classes (especially around response generation) for derivation or replacement. One of the most popular requests was e.g. to customize the response of the introspection endpoint and redirect handling in the authorize endpoint. Oh btw – endpoints are now extensible/replaceable as well.
Support for the ASP.NET Core config system
Clients and resources can now be loaded from the ASP.NET config system, which in itself is an extensible system. The main use case is probably JSON-based config files and overriding certain settings (e.g. secrets) using environment variables.
We also updated our docs and the satellite repos like samples, EF, ASP.NET Identity and the quickstart UI. We gonna work on new templates and VS integration next.
If you need help migrating to v2 – or just in general implementing IdentityServer – let us know. We provide consulting, support and software development services.
Last but not least – we’d like to thank our 89 contributors and everyone who opened/reported an issue and gave us feedback – keep it coming! We already have some nice additions for 2.x lined up. Stay tuned.
It feels weird to look at your versioning. IdentityServer4.2 would have been more natural?
well – 4 is the generation. The version uses semver.
I’m working with a ASP.Net Core 1.0.1 web application and Identity Server 3. Both are still using project.json format. I need to migrate all the code to something that has MS Long Term Support (LTS).
What version of .Net Core, anywhere between 1.0.5 runtime / 1.1.0 SDK and 2.0 runtime / 2.0 SDK, do you suggest I target for the simplest upgrade path? I will accordingly decide if I’ll continue to use Identity Server 3 or switch to Identity Server 4 (or even v2). Thanks!
see here for support
ASP.NET Core 1.x == IdentityServer4 1.x
ASP.NET Core 2.x == IdentityServer4 2.x