Cross platform authorization with Web API 2

Question

I have a WEB API service that I intend to use with clients that range from browzers to mobile apps to windows desktop clients. All the authorization examples and documentation I have come across are more related to using claims (which only works using cookies sent from a browser?) and through that controlling access to certain action methods on MVC controllers.

How do I use such claims in a web api environment for clients that are not just browsers? I am currently using tokens that are basically generated by my website and so I post the token on every request made to the web api. This is currently only good for authentication. But I dont want every logged in user to be able to get that token from the html and make service calls to other web api methods that they dont have access to. I dont want that data to be made available through such a "hack".

Any thoughts on how this is done or am I missing something in the documentation here?

EDIT

I thought I should mention this. I don't want to use Entity Framework for any user management. Somehow EF seems to be tightly integrated with all user and claim management in all examples online.

Answer 1

For Web API you have to use OAuth 2.0 bearer access tokens, for MVC you have to use Cookies, do not mix between the both, Web API will serve your mobile clients, SPA apps, and MVC will serve your web application if you planning to build one. You can read detailed 5 blog posts here which describes how you can build simple authorization server using Web API and Identity.

Answer 2

I'm going to try and break down your question into several key components to consider. This is a big topic with options and variations you can apply to each area. If you have a Pluralsight account (or can get a free trial) I would recommend checking out Dominick Baier's excellent Web API v2 Security course at: http://www.pluralsight.com/courses/webapi-v2-security.

Based on your need to support a range of clients, I would recommend the OAuth 2.0 protocol as the place to start and will explain more.

• Authentication. OAuth 2 is not an authentication protocol, and does not dictate how authentication is handled by your application. You have the option of using any secure method, including Enterprise Library application blocks. One common method with OAuth 2 and varied client types is to use a standard web based login page using ASP.NET forms authentication which generates a cookie based authentication token. This cookie can be exchanged for an OAuth 2 bearer token via a token issuing endpoint as described below.

• Token generation. There are many security concerns to consider when generating a secure token for use in calling a protected API. I would encourage use of an existing library or package to create what is known as an OAuth 2 "authorization server" to securely generate these tokens. This may consist of using ASP.NET Identity (http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server), a self-hosted third party authorization server (https://github.com/thinktecture/Thinktecture.IdentityServer.v3), or a third party hosted authorization server (http://msdn.microsoft.com/library/hh147631.aspx).

• Authorization. The are two primary ways to handle user level authorization with OAuth 2 bearer tokens. The first is to embed claims or other authorization data in the token itself, and the second is to use the token to perform a lookup that retrieves this authorization data. If role based authorization is sufficient for your needs you may want to consider including each role as a separate claim in the issued tokens. This is likely the simplest solution and allows use of the [Authorize] attribute to decorate Web API controllers and actions to enforce authorization: http://msdn.microsoft.com/en-us/library/system.web.http.authorizeattribute%28v=vs.118%29.aspx.

• Application management. The OAuth 2 protocol requires that each application (usually each client type) is assigned an identifier and key. How these applications are "registered" and assigned these credentials is left up to you, but is generally handled by your authorization server library or service.

• Token management. The OAuth 2 bearer tokens generally are given a short lifetime and must be re-issued once they expire. A feature to make this easier is known as "refresh tokens" and allows clients to automatically recycle their bearer tokens to ensure they have an active one.

You may now have more questions than when you started. I would recommend spending some time with resources like the Pluralsight course mentioned above the ASP.NET Identity documentation and samples. You will likely need to pick and choose specific elements for your needs as you better understand how each component fits into the bigger picture.