It’s the time of the year – we are working on IdentityServer and lock down the features we want to implement for the next version(s).
Initially we planned to make our 3.0 release the big one – but then .NET Core 3 happened and we had to synchronise our release with Microsoft. That meant we really didn’t have the time to make the changes we wanted to.
This is different for v4 where we have much more control of the schedule. You can imagine that a lot of backlog has accrued over the last year and that many people have many opinions on what we should add or change or fix or whatever. But instead we picked five main themes that we think are important to improve IdentityServer as a whole.
Currently we plan to release 4.0 around June. After that we will work on 5.0 which probably will be released with .NET 5 (December-ish).
So here are the five big things we plan to do:
Make it easier to migrate to different signing algorithms
This is already done – and a more thorough description can be found here.
Make Proof-of-Possession tokens easier to use
Again, this work is already done, see the blog post here.
Update scope and resource design
Our scope validation system is a bit dated and not extensible at all. Our scopes were designed to be static, but newer scenarios like dynamic and structures scopes came up after that. In addition we are adding support for resource indicators which will give you more control over the shape of access tokens. This allows for isolating resources (meaning you can prohibit the issuance of an access token that is valid for more than one resource) and resource specific token content/processing.
Harden Refresh Tokens and make them more secure for SPAs
Refresh tokens in SPAs become a thing (and we can’t stop that). We already have a good feature set around refresh tokens to make them more secure, e.g. sliding expiration and one-time tokens. One missing feature though is detecting multiple refreshes so we can automatically revoke access. This requires some internal changes but it’s worthwhile.
Re-design Logging and Eventing
This is a huge one and might have to be moved to v5. But in essence we want to go fully structured/semantic and also give more control to the implementer – commonly requested features are full control over log levels, redaction of content, transformation of data, splitting of log streams etc… I am strongly leaning towards using the new System.Diagnostics.DiagnosticsListener API for that. Feedback welcome.
Of course there are some smaller issues that might get picked up along the way and you can see a full list here.
As always we encourage you to give feedback and try the new features – we will keep you posted as soon as something is ready.