Sharing authentication methods across API and web app

apiasp.netauthentication

I'm wanting to share an authentication implementation across a web application, and web API. The web application will be ASP.NET (mostly MVC 4), the API will be mostly ASP.NET WEB API, though I anticipate it will also have a few custom modules or handlers.

I want to:

Share as much authentication implementation between the app and API as possible.
Have the web application behave like forms authentication (attractive log-in page, logout option, redirect to / from login page when a request requires authentication / authorisation).
Have API callers use something closer to standard HTTP (401 – Unauthorized, not 302 – Redirect).
Provide client and server side logout mechanisms that don't require a change of password (so HTTP basic is out, since clients typically cache their credentials).

The way I'm thinking of implementing this is using plain old ASP.NET forms authentication for the web application, and pushing another module into the stack (much like MADAM – Mixed Authentication Disposition ASP.NET Module). This module will look for some HTTP header (implementation specific) which indicates "caller is API".

If the header "caller is API" is set, then the service will respond differently than standard ASP.NET forms authentication, it will:

401 instead of 302 on a request lacking authentication.
Look for username + pass in a custom "Login" HTTP header, and return a FormsAuthentication ticket in a custom "FormsAuth" header.
Look for FormsAuthentication ticket in a custom "FormsAuth" header.

My question(s) are:

Is there a framework for ASP.NET that already covers this scenario?
Are there any glaring holes in this proposed implementation? My primary fear is a security risk that I can't see, but I'm similarly concerned that there may be something about such an implementation that will make it overly restrictive or clumsy to work with.

Best Answer

I don't quite understand what it is you actually want to share.

I'd assume you won't find a framework cause what you want to do is not that hard to solve.

1) A third party application is -only- going to touch your general purpose API. It uses API authentication only (through forms authentication, api key usage, take your picking).

2) Your own application through user actions will redirect to login page and such and have it's own picking of authentication (form authentication probably). This is about stuff the user can potentially enter through the address bar of the webbrowser. If your application happens to use your general purposed API under the hood you are not going to redirect the user to your login page on ajax calls. Your application should handle/prevent this for the user. A user is not going to make API calls through his/her browser's address bar.

So for your application to be able to use your general purpose API, the general purpose API would only need to support the same authentication scheme (form authentication). Or your application would have to fetch the user's api key or something to use after the user logged in.

You can easily create an Authorize attribute in MVC that will checks multiple options, first for an api-key, then for a forms authentication based cookie token. If it finds nothing your general purpose API should or needs to throw 401s only.

Your application would pick them up from ajax call failures and could decide to move the user over to the login page.

Related Solutions

ASP.NET Authentication – How Does Authentication Work with ASP.NET Using Live ID or Windows Authentication

I would use sessions. You can store the information you need after they've logged in, be it a token given by the login service or even just an isLoggedIn boolean value.

Then, you can check in pages that need it (Inheriting from a base page class is great for this) that the information is there. If not, kick them back out.

So, in your code that processes the response from the claims-based auth (I do a lot of work with CAS and Shibboleth, two claims-based systems in heavy use in academia), you'd do something like :

if(isSuccessfulLogin)
{
    Session.Add("isLoggedIn",true);
    Session.Add("userId", userIDfromService);
}

Then, in your Page_Load method, you'd just do something like:

if(Session["isLoggedIn"])
{
    // do whatever
}
else
{
    // redirect somewhere
}

These are very simplified, and leave out the details.

ASP.NET MVC – One Login Across Multiple ASP.NET MVC Applications

It sounds like your unique requirements dictate that you are indeed on the right track that you will need an external universal authentication provider for all of your applications, especially the requirement that a change in Membership Provider as you put it cannot and should not result in a new release for your application.

At a universal authentication provider you can control which sites use which membership providers and can even subjugate responsibilities like delegating Roles and Privileges to various users after authenticating them.

I advise caution however on the WCF approach as it seems SOAP based web services are slowly being replaced in importance by REST based web services like what is offered in ASP.NET Web API. The future of applications is mobile, and every major mobile development platform has strong support for REST based web services.

If you even have the slightest doubt that you might need to extend membership provider support to mobile applications eventually then it is a good idea to forgo WCF. Furthermore, REST based web services allow better integration by third parties (perhaps clients wanting to integrate with your software package?) to communicate with your application and retrieve information from it.

As far as authentication protocols for REST based web services, there doesn't appear to be a good out of the box way to do this, but security is rather essential. There is a good article on how to secure your authentication requests to your authentication provider application. http://codebetter.com/johnvpetersen/2012/04/02/making-your-asp-net-web-apis-secure/

Best Answer

Related Solutions

ASP.NET Authentication – How Does Authentication Work with ASP.NET Using Live ID or Windows Authentication

ASP.NET MVC – One Login Across Multiple ASP.NET MVC Applications

Related Topic