some notes from work

Ways to approach Web API Security
There is a significant difference between MVC Controller types and ApiController types. The former has route-specific actions which may be named anything and the later has verb-specific actions named Get, Post, Put, or Delete. The former has access to session and cookies while the later does not. Cross-talk between an MVC Controller and an ApiController cannot rely upon session (or cookies) for authentication and authorization. So how should authentication and authorization behave?

• state across a mishmash of session and cache
  Both an MVC Controller and an ApiController may access the cache. The cache is globally accessible without regard to who the user is or which browser at which IP is reaching in. In order to store user specifications in the cache that are not exposed to all users, the key for the cache may be session driven. An ApiController cannot use session, but the key could be handed in to all ApiController actions from the greater MVC application. (There is the assumption here that all controllers, both MVC and Web API, will be kept in the same application at the same subdomain, for as much is a requirement.) A cache entry containing a user's credentials would, for security sake, need a terse (perhaps twenty minutes) time to live before expiration, but the cache setting for a user could also be constantly recreated whenever a new MVC Controller action was hit so that the lifespan of the relevant piece of the cache was bound to the life of the session. Where session was available, an AOP process could, before executing an MVC Controller action, check to see if a unique key (perhaps a GUID) for the session existed and make one should it be lacking. Such an AOP process would also upkeep the cache entry made with the session-specific key, tucking an object inside to represent a user's identity (perhaps an IPrincipal).
   
• state communicated by web tokens
  MVC controllers may hand Simple Web Token (SWT) type tokens into the Web API to communicate whom the user is. A symmetrical key (same at both the sender and the receiver) would need to kept at both the server and receiver for decoding the messages, but assuming that all MVC and Web API controllers were kept in the same application at the same subdomain, such a key could just be kept in cache for all controllers to reference. Replacement keys would need to be regularly rolled out in the name of security.
   
• OAuth 2.0
  Complicated mechanics which could not exist independent of a different single sign on implementation (such as Thinktecture's) without clumsy architecture, are offered in the OAuth 2.0 security specification. As this is envisioned to work, a user will have two independent logins at two applications and need the first application to have limited API access to the second while not desiring to outright store the second applications login credentials at the first app. An HMAC (Keyed-Hashing for Message Authentication) token is procured from an authentication server (perhaps Google or Facebook) and used by one application to access another application via an API with selective, context-appropriate permissions. The first app must advertise its own credentials to the authentication server, but the second app does not necessarily need to do so. The credentials affirm that the token, carrying merely a username and some metadata, does not need to be validated every time it is used with a check against a data store. The authorization server then hands the first app an authorization code and the app redirects to the login screen of the second application where the authorization code appears as a variable at the URL. The second app may use the code to know a few things about the process at hand, including the need to redirect back to the first app after granting permission (by way of login) to use the access token.
  
  In the OAuth 2.0 approach the way in which the access token is validated by the second application at the authorization server is not set in stone. Different implementations may take different approaches. The application giving its credentials to the authorization server, the client, may be given a refresh token at the same time it receives an access token. Access tokens will be short lived while the refresh tokens offer a means to get new access tokens without resubmitting log in credentials. The preceding description of OAuth 2.0 comes from Pro ASP.NET Web API Security by Badrinarayanan Lakshmiraghavan who compares access tokens to valet keys, keys which may open the car door and turn the ignition without allowing access to the glove box or trunk, i.e. keys for a very specific role in contrast to keys which allow blanket access to every lock (which are akin to the direct logins at the "second application" in the example above). Again, one of the goals of OAuth 2.0 is to prevent the exposure of unfettered access to a dependency to a depending party.