OpenID Connect and the IdentityServer Roadmap

Since OpenID Connect has been officially released now, I thought I’ll tell you a little bit more about our plans around our identity open source projects.

IdentityServer
IdSrv is a very popular identity provider with excellent support for WS-Federation and WS-Trust. It has decent support for OAuth2 and OpenID Connect (basic client profile) since quite some time – but these protocols were more like an afterthought than part of the initial design. IdSrv uses by default the pretty dated ASP.NET membership, but can be easily extended to use different data stores.

AuthorizationServer
We built AS because we wanted to implement OAuth2 “the right way” and we thought it is easier to start from scratch than retrofitting it into IdSrv. We deliberately didn’t add any authentication / user management pieces to AS because we wanted it to be freely combinable with existing infrastructure. For people without existing infrastructure, this was often a problem because setting up the IdP and AS at the same time was a steep learning curve.

While both projects solved very specific problems, there was room for improvement:

• Combine identity management and a full featured OAuth2 implementation in a single component – still be able to use them independently if needed
• Make it more lightweight so it can be hosted more flexibly
• Incorporate OpenID Connect true cross platform client / relying party support (which was always a problem with WS-Federation)
• Make authentication and acquisition of access tokens possible in a single round trip – which is a scenario that becomes more and more common.

So we actually decided to combine all those improvements and feature ideas into a new project currently codenamed “IdentityServer v3” :

• Single codebase and server component to deploy
• OpenID Connect and OAuth2 as the core protocols – but extensible to add support for e.g. WS-Federation
• Built as an OWIN/Katana component with no dependencies on a specific host (e.g. IIS)
• Completely customizable – think “STS toolkit”
• Ability to incorporate arbitrary identity management systems – support for Brock’s MembershipReboot and ASP.NET Identity by default
• Separation of core STS and user / configuration management for more flexibility
• ..and more

We are not done yet – but will have more details soon – in the meantime – here’s a preview screenshot of a consent screen for a native client requesting identity claims (user id and email) as well as access tokens for an HTTP API backend.