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!
HTH
leastprivilege.com 
Hey Dominick,
First up, let me thank you for the awesome knowledge that you brought to the community with the thinktecture implementations. I have a small issue with JWT and AS. How do you validate the JWTs that are issued through the AS. I’m not sure if I’m missing something but just can’t my head around configuring the host application to validate the tokens received from a client against the AS. I’ve been looking at the all the vimeo videos but the sample only describes a scenario where the JWT issuer is a custom self issuer (?).
Cheers!
Shiran
See here:
https://github.com/thinktecture/Thinktecture.AuthorizationServer/blob/master/samples/Flows/ResourceServer%20(Web%20API%20v1)/App_Start/WebApiConfig.cs
Hi again, what I’m not sure is how “issuer: Constants.AS.IssuerName,” (of which the value is just AS) is getting wired up with the authorization server. Is there any other configuration to map AS with a real token validation endpoint ? Or am I missing something ?
There is no token validation endpoint – in the web api you need to know three things: the issuer name of the AS, the audience and the signing key.
IssuerName is the issuer name configured in AS.
I’m confused, is this article referencing identityserver v2 or v3? Should I be using AS and IDS v3? Or can I just use IDS v3 and not use AS?
Given the date it was written – it related to v2.
V3 will replace v2 and AS – but it is still under development.
Good work!