An authorization server is a very important architectural component when it comes to Web API security – think of it as a traffic cop between clients, users and resources. The OAuth2 spec defines it as follows:
“The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.”
It is highly recommended that you factor out all authentication and delegated authorization concerns to an authorization server right from the start. This will simplify your security architecture dramatically.
Building a full featured authorization server is a lot of work and definitely requires some experience in the security space – that’s why we built Thinktecture AuthorizationServer so everybody can benefit and learn from it. We support a full application and authorization model around clients, flows, scopes as well as many options around consent pages, refresh tokens etc – if you want to read more about it, check our wiki.
But there are also situations where the learning curve around all these technologies is a little too steep, the infrastructure requirements are too high (remember that an authorization server needs be highly available etc..) or the project requirements are not complicated enough (yet) to justify the effort.
For these situations, ASP.NET Web API v2 includes support to add simple authorization servers right into your business resource servers. This way you can use the authorization server/OAuth2 pattern right from the start without being blocked by infrastructure/political complexity. The authorization server middleware allows implementing only the OAuth2 bits that you need and is typically hard coupled with the resources they protect. In my following posts I will look at some scenarios this new middleware enables.
Once your scenarios get more complicated (e.g. many different client types and platforms, many resource servers and endpoints, more complex security requirements), you’ll realize that OAuth2 itself is not the really the issue – but rather the management and policy enforcement that comes with it and needs to be implemented anyways.
When you reached this point, you can decide if you want to extend and modify the built in authorization server framework or simply switch to an authorization server that has the features you need already built-in (e.g. our AuthorizationServer – or some commercial product).
The good news is, since you use the OAuth2 patterns right from the start, the changes to your application are minimal – the client requests tokens from a different URL, the resource server uses a different signature to validate incoming tokens – job done. That’s the beauty of this model.
leastprivilege.com 
Pingback: Embedding a simple Username/Password Authorization Server in Web API v2 | www.leastprivilege.com
I have been playing with both your Authorization Server and the OWIN one for some simple stuff. I used the OWIN Authorization Server for a project because we only needed a very little subset of the flows and it was really easy to set things up there. With the SPA template in visual studio it was then easy to use the external login bits and aspnet Identity for the project.
Now that I need more flows and not really want to burden my own head with the security things and just want to use your authorization server implementation. Would it make sense to plug your AS into the OWIN Oauth2 implementation as a Provider, if not why?. Is it something you have considered?
What would that give you? Just the ability to host the AS inside the RS – which I think does only make limited sense.
Dominick,
I am trying to get my head around your Authorization Server, Identity Server, and how to use them with the SPA template in Visual Studio 2013. I have downloaded the latest and have running your examples from Authorization Server and IdentityServer and new IdentityModel but I am missing something on how to register my SPA in Authorization Server, modify an SPA template project to point to AS.
Hi Dominick,
Thank you for all the knowledge you share. For many things I use your GitHub repos and blog as primary source. I do have a question, which I hope you have time to answer.
I know it’s a strange question, but still, I can’t find a clear answer to it. When do I know I need to have my own Authorization Server? I know I have some Web APIs that I will protect with OAuth2 tokens. Can I use Authorization Server from Google or Azure? Or do I have to protect my own Resource Server with tokens from my own Authorization Server?
Thanks a lot. I really appreciate if you have time to sort this one out for me.
Bjørn
To protect your own resources, you need your own authorization server.
Thanks. That makes sense. I’m still confused by the “ADFS JWT bearer token middleware” in the NuGet packages “Microsoft.Owin.Security.ActiveDirectory”. Seems to allow use of bearer token from ADFS on Web API hosted anywhere.
I know it’s old, but Vittorio explains how Azure can be used similarly here http://www.cloudidentity.com/blog/2013/07/23/securing-a-web-api-with-windows-azure-ad-and-katana/
What am I not getting?
Thanks
Not sure what you are not getting ;)
Hello,
very interesting post. You mention that “ASP.NET Web API v2 includes support to add simple authorization servers right into your business resource servers.”.
However, looking at the web api help (http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api) it seems this is the only help and it doesn’t related to OAuth2.
I found this interesting OWIN OAuth 2 Authorization server (http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server), however from what I understand, it implies to have a self-hosted OWIN server, thing that I already implemented for another project as a Windows service, while WEB API would be hosted directly in IIS.
The OWIN OAuth2 server offers one thing I absolutely need: Client Credentials Grant. I’m wondering if it is possible to achieve that using WEB API2. If yes, can you point me to any only ressources? I would prefer having a solution hosted on IIS, but it is not a must.
Best Regards,
Nicolas
You can use the Katana OAuth support for simple scenarios – otherwise use IdentityServer3.