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.

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.

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.


This entry was posted in AuthorizationServer, IdentityModel, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI. Bookmark the permalink.

24 Responses to OpenID Connect and the IdentityServer Roadmap

  1. baotao says:

    Worth the wait. when you can publish v3?

  2. Probably sometime mid year.

  3. Giddy with excitement Dom :)

  4. mrdan says:

    Have you considered some form of SCIM support for v3?

    • Yes – but we postponed it. The nice thing about v3 is, that user management and configuration is completely separate from the core engine. So it would be easy to add once we (or anyone else) decides to.

  5. Jeffrey Fulller says:

    So how does this fit into the scheme of things if we’ve already implemented IdSrv v2 and AS v1?

    • Didn’t I explain that? I’s v.Next

      • Jeffrey Fuller says:

        Ok, so its just a replacement for IdSrv v2. The way you talked about combining things, I was unclear as to whether this meant you were basically combining IdSrv and AS, such that AS would not longer be becessary.

      • Yep we are combining it – IdSrv and AS together become IdSrv 3. But that’s not an immediate thing.

        We are building v3 from the ground up to be oauth/openid centric.

      • Jeffrey Fuller says:

        Well, that sounds great to me. That is pretty much exactly what I was looking for when I started the aforementioned project. If only I’d got started 9 – 12 months later ;-)

  6. cotepatrice says:

    Great news ! I like the fact that it’ll be easier to setup initialy and that both IdSrv and AS will still be usable independently. Can’t wait to see your OpenID Connect implementation.

  7. This sounds great. Having used Brock’s Membership Reboot library as the starting point for my centralised identity management I think this is probably the missing piece for me to implement a fully fledged sso. If I am understanding the role of Identity Server 3.0.

    I take it with this new version I can keep all my existing user management portal that I have built to maintain my users with Brock’s MR library and then hook in the authorization service to handle cookies etc.

  8. cumpsd says:

    Looking forward to this :)

  9. wtfChris says:

    I beg of you.. PLEASE PLEASE.. when you release v3 please include tutorial documentation that walks through the samples. I’ve downloaded V2 and its like trying to build an automobile with a pile of parts and no instruction manual. I’m no security expert, I’m just a dev trying to defend my REST services with OAuth tokens and an STS backed by Facebook and ADFS. I _KNOW_ the product supports it, but 3 days later and I’m still trying to decipher the various configuration settings. I can’t be the only one overwhelmed by this space. A little guidance on leveraging the tools would be much appreciated.

    • Well – we do our best. But it is not our job to teach you the technology. We try to come up with an comparably easy implementation of that technology.

      Since this is open source and a community effort etc – feel free to write about what you learned. I am happy to link to it in our wiki.

      • wtfChris says:

        Sounds like a great idea. Once I figure out how to configure the STS for Google OpenId, I’d be happy to publish a step by step guide.

    • Connie DeCinko says:

      I agree. A great solution is pointless without instructions on how to use and implement it. None of us are mind readers and cannot glean how the code is intended to be used.

  10. Pingback: Announcing Thinktecture IdentityServer v3 – Preview 1 |

  11. Hi,

    And the OpenId connect protocol will be implemented only in Identity Server, not in Authorization Server?? Because , the last token returned from authorization server is different that oauth access_token, really ???

  12. Just finished watching the intro videos and this looks great. Looking forward to the first Beta release. Glad you decided to combine IS and AS – it really was a bit of an uphill battle to set everything up for the first time with no prior experience with these projects. More documentation will certainly help. Either way – great stuff!

  13. Nick McCollum says:

    Will IdentityServer v3 continue to have out of the box support for WS-Federation or will I have to extend it and add that capability myself when moving from v2 to v3? If so, it sounds like we are losing some features in v3 that were present in v2.

Leave a Reply to Dominick Baier Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s