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.
Filed under: AuthorizationServer, Katana, OAuth, OWIN, WebAPI
