Today is a big day for us! Brock and I started working on the next generation of IdentityServer over 14 months ago. In fact – I remember exactly how I created the very first file (constants.cs) somewhere in the Swiss Alps and was hunting for internet connection to do a check-in (much to the dislike of my family).
1690 commits later it is time to recap what we did, why we did it – and where we are now.
Having spent a considerable amount of time in the WS*/SAML world, it became more and more apparent that these technologies are not a good match for the modern types of applications that we (and our customers) like to build. These types of applications are pretty much a combination of web and native UIs combined with web APIs. Security protocols need to be API, HTTP and mobile friendly, and we need authentication, API access and identity delegation as first class citizens.
We had two options – either try to retrofit the new protocols into the old WS* architecture (like so many commercial products do) or start from scratch. Since we also had a number of other high priority design goals for the new version we decided to start from scratch.
Some of the highlights of IdentityServer3 (at least in our opinion) are:
Support for the modern security stack
OpenID Connect and OAuth2 that is. These two protocols in combination are the perfect match to build the modern applications we had in mind. OAuth2 is used to manage access (and access control) from clients to APIs for both trusted subsystem and identity delegation systems. OpenID Connect is the extension to OAuth2 for implementing rich authentication and single sign-on scenarios for any application type.
Hosting
We wanted to be much more flexible in our hosting scenarios – IIS vs self-hosting, Windows vs Linux, ASP.NET vCurrent vs vNext, Embedded into the application vs separate standalone vs separate web farm vs cloud – you name it. Regardless which hosting environment you choose – IdentityServer is always the same.
Flexibility and Extensibility
IdentityServer2 always had a dependency on a database. The past years taught us that there are many situations where this is not appropriate. In the new version everything is code first and abstracted behind interfaces. Everything can be done in memory and no persistence store is required. We have an optional extension that uses Entity Framework for persistence – but this is up to you.
Another issue we had in the past was that there were too many situations where one had to change the core source code to implement some custom workflow. In IdentityServer3 we think we did a good job in anticipating the typical (and not so typical) modifications and baked them right into the core runtime as extensibility points. So far this has worked out really well.
Framework vs Server
As mentioned above – IdentityServer3 is all about customization and extensibility. The developer is in the centre and we give him lots of freedom in changing almost any aspect of the workflow. This is the big difference to many commercial off the shelf products.
Right from the start we used the term “STS Framework” rather than a “Server” and up to today we don’t even have an admin UI for managing the server configuration. We (and most people we spoke to) were absolutely fine doing all of that in code and in their custom configuration system. That said – we have an admin service and UI in the works that will be released soon – but again this is totally optional.
Brock and I just recently spoke to Carl and Richard about these design goals on .NET Rocks.
Where to go?
To accommodate the new versioning scheme (we switched to semver) and the componentized architecture we changed both the GitHub organization and repo names as well as the Nuget package names. The new organization can be found here and the main repo is here along with instructions on how to contribute and an issue tracker for filing bugs or giving feedback.
The new docs site gives quite a bit of background and can be found here – or you can jump directly to our samples.
If you need consulting about modern (or not so modern) security architectures in general and IdentityServer in particular – you can contact us via email at identity@leastprivilege.com or via twitter: @leastprivilege & @brocklallen.
What’s next?
We have a couple of “side projects” that complement the core IdentityServer3 – there’s IdentityManager, which we neglected a bit for the last months, and there‘s the admin service and UI (good people are working on that right now)…And there are of course new features to implement for IdentityServer – check this label and take part in the discussion.
Last but not least
The last 14 months were astounding – we got more feedback, questions, bug reports, PRs and help on IdentityServer3 than all other OSS projects we did before combined. You guys were fantastic! Thanks for your help – we hope you enjoy the result (..and keep it coming)!
Thanks!
Dominick & Brock
leastprivilege.com 
Congratulations! Looking forward to the Admin API & UI.
Congratulations! Great to See that. We use IdSvr3 some couple of month, although it was in alpha and beta state. We use it for a complete new web-based generation of our products and we want to go online in March with it. So good timing guys! :) We are absolutely happy with the security, comfort and flexibility of IdSvr3 and it is going to be our company standard here at Fairmas! Thanks a lot for all the great work done!
Reblogged this on brockallen and commented:
After a lot of work, Dominick and are have released IdentityServer3. His post sums it up perfectly. And thanks to all of the feedback we’ve received.
Wow, abandoning the existing and established standards? Bold move… So what are people that need those standards supposed to do?
We are not going to take v2 off the net – this is still working – but done.
That said – we support WS-Federation in 3 as well.
Congrats guys, your hard work have had a massive impact on the way we design our latest projects and the importance we are placing on security with everything that is happening in the world today. We offer our clients a whole new architecture & design for their next generation applications, safety and security being core. Keep on going please!
Hi Dominick, I’m trying to understand and get my head around the AspNetIndentity sample and so far failing miserably!
There is a lot of magic happening somewhere and I cant locate it :) How are the views being generated and how do I customize them? How are the routes generated?
Sorry if the questions seem to basic but I would really like to understand the sample better before fully adopting Idsvr3.
Check the docs and then use the issue tracker for questions.
Thanks will do.
Congrats… great work guys…
thanks!
Congrats! I’ve already created a working IdentityServer v3 with custom views and Membership Reboot – I LOVE the extensibility. I have a question though – I’ve defined some custom scopes for my server and added some custom claims to them – those are not being returned even though the client is requesting them – what am I doing wrong? :)
Please use the issue tracker on github for questions. That’s the easiest.
We are implementing an application using Angular (no web server) + WebAPI and Identity Server. We are currently planning to use the implicit flow (client requests for token + id_token). I have a few questions.
1) What is essentially the purpose of the /endsession end point. The code in the controller seems to do very little. I think in my scenario “logging out” really just means emptying the access_token property in our Javascript model, right?
2) Isn’t it right to say that the access token life span dictates the session length in the browser? Since we can not store a refresh token in the client (see question 3 too) we can only ask the user to log in again when the access token expires.
3) I would probably get the kind of flow I want if IdentityServer sent the SPA a refresh token in a secure, http-only cookie instead of using a URL fragment. This way I could ask the IdentityServer for an access token and the IdentityServer would get the refresh token from the cookie. This would probably need some extending/modifying in the IdentityServer code. What are your thoughts about this, do you see it would be feasible and doable?
Thanks in advance.
Hi,
please use the issue tracker on github for questions. This way it is all documented in one place.
Good job guys! The UI thing seems like a big help.
A beautiful concept and product. However, there is a significant block to learning it at the most basic level. I wanted to experiment with it so I went to the starting point. “Getting Started: Creating the simplest OAuth2 Authorization Server, Client and API”
In that description you display code segments by never the complete solution. That is a shame because if I wasn’t so stubborn I would have given up yesterday. What is most critically missing is the “using” statement required for each code block.
The worst was the definition of Oauth2Client in the following code block
static TokenResponse GetUserToken()
{
var client = new OAuth2Client(
new Uri(“https://localhost:44333/connect/token”),
“carbon”,
“21B5F798-BE55-42BC-8AA8-0025B903DC3B”);
return client.RequestResourceOwnerPasswordAsync(“bob”, “secret”, “api1”).Result;
}
Incorrectly thinking that OAuth2Client would be part of the DotNetOpenAuth.OAuth2.Client definition from NuGet, I spent hours trying to get it defined in DotNetOpenAuth and in OWIN.
Finally I took your whole code block and Googled it, finding its reference to Thinktecture.IdentityModel.Client which by the way is ambiguous with
using Thinktecture.IdentityServer.Core.Models that contains its own TokenResponse.
What I would suggest is commenting any possible ambiguities with any package such as OWIN or DotNetOpen i.e.
static TokenResponse GetUserToken() // Requires using Thinktecture.IdentityModel.Client;
I think you product is an important contribution the OpenId Connect.
Please just think of your potential users as entering a huge learning curve and needing a complete, working, starting point no matter how simple.
Thank you
Jim Lennane
Thanks.
The full source code can be found here – https://github.com/IdentityServer/Thinktecture.IdentityServer3.Samples/tree/master/source/Simplest%20OAuth2%20Walkthrough
I updated the docs – and btw – so can you when you think you can improve the text.
OAuth2Client is from the Thinktecture.IdentityModel.Client nuget package (why would I use DotNetOpenAuth) – and I explicitly mention to install that package with the install-package command. So I am not sure what the problem is – maybe you missed that.
Anyways – please use the issue tracker on github for the various repos to leave comments (including the docs repo) when you run into more problems.
Your product deserves a good reference and example book. Pro ASP.NET Web API Security. I hope Apress will soon agree.
Thank you!
(stop building own solution)
(start using IdentityServer3)
You guys are awesome and thanks for the wonderful product. I have started my implementation on v3.
Great article Dominick.
I am planning to built security (authentication and authorization) around my web api using identity server. On a high level, I have a working rest api. I want to use identity server (as another server) to authenticate (with my own database tables using EF) and authorize. There seem to be many examples and was wondering if you can help point me to the right place.
Check the docs and walkthroughs.