We released a preview version of AuthorizationServer this week. AuthorizationServer is an implementation of the OAuth2 design pattern and helps making API authorization easier.
IdentityServer also has OAuth2 endpoints – so you might ask yourself why we started from scratch with a new project and did not just add more features to the existing IdSrv endpoints. We were also discussing this quite a bit – here’s a summary of our thinking.
Separation of authentication and authorization
AS (as the name implies) is all about authorization (see my post). We specifically designed AS to be composable with arbitrary authentication systems. That could be via the .NET built-in WS-Federation support to IdentityServer, ADFS or Windows Azure Active Directory…or by adding forms or OAuth based authentication to it. Even integrated Windows Authentication would work fine. I’ll talk more on how to implement those scenarios in future posts.
New technologies, new APIs – a clean slate
IdentityServer is heavily based on the WIF token service pipeline. That’s a great thing for implementing WS* style protocols like WS-Federation, WS-Trust and even SAML2p. For OAuth2, OpenID Connect and JSON Web Tokens, that pipeline is not optimal. To get the most out of those technologies, we had to start with a fresh design. There were other lessons learned from building IdentityServer (database access, dependency injection, UI…) and we are using different approaches now internally.
The future of OAuth2 in IdentityServer..and IdentityServer in general
We want to keep authentication and authorization separate. That means for IdentityServer that we will shift our focus back to authentication and user management and that we’ll move everything authorization related to AuthorizationServer. We will not immediately deprecate the OAuth2 support in IdentityServer – but all new features and improvements go int AS. That said – we have some great features planned for IdentityServer – stay tuned!