CODEWITHSUNDEEP
asp.netasp.net-mvcasp.net-mvc-3asp.net-web-apiasp.net-web-api2
Jatin
Jatin

Reputation: 4063

Using Token based Authentication in already existing mvc project

There is an existing mvc 3 application that is using asp.net Membership authentication (subclass of System.Web.Security.MembershipProvider). This application was only accessed using web browser.

Now, there is a need for the application to support a Mobile App, and I have already introduced WebApi 2 Controllers into the project for handling the Mobile App requests.

The problem is that I don't have a clear thought of how to Authenticate the Mobile App users.

It seems that I have to provide Token type authenticating mechanism where the Mobile App has to submit the Token (issued after authenticating) with each request. But I am not sure how to implement it (like what frameworks/packages to use), and get it working side by side with the existing MembershipProvider

So, how do I provide a way to authenticate Web Api requests, and also retain existing asp.net MembershipProvider for MVC Controller requests.

Also, if this could be done better in some other way ?

Upvotes: 1

Views: 3273

Answers (1)

Wiktor Zychla
Wiktor Zychla

Reputation: 48279

It doesn't have to be "token" that authenticate mobile users.

The notion of tokens used to authenticate webapi requests got a lot of attention because of the OAuth2 protocol that has been adopted to the .NET world by the DotnetOpenAuth and then the OWIN. OAuth2 supports multiple "flows" and what is interesting is that beside "passive" flows (where browser redirects to an external login page) there are also "active" flows (designed for active clients like mobile apps).

Thus, switching to OAuth2 means that you are using a coherent authentication protocol supporting all major scenarios.

One of the possible approaches for you (and you seem to be interested) is to adopt the token approach to authenticate webapi requests. This is possible but this means that you have two different authentication approaches side-by-side, the cookie-based forms authentication for passive clients and token-based authentication for active clients.

I would say this kind of smells.

I would rather think of a uniform approach.

Either move towards OAuth2 completely, which means you adopt DotnetOpenAuth/OWIN for both passive and active clients.

Or you stick with Forms Authentication and just enable it for your active clients.

The latter is rather simple. Instead of carrying tokens, your active clients carry forms authentication cookie. To issue such cookies, you just expose an anonymous webapi method that expects a login and password and appends a forms cookie to the response.

Assuming you clients support cookies, forms cookie issued by the server are used in consecutive requests and all you have to do is to have the Authorize attribute over your web api methods. The forms module will pick up the cookie and populate the IPrincipal for the lifetime of requests just like it does for regular requests.

To summarize:

Moving towards token-based authentication:

Pros:

  • in future you could easily handle more complicated authentication scenarios (like for example using external authentication providers)
  • token-based OAuth2 is commonly used nowadays so you can more easily integrate with other applications

Cons:

  • migration could cost: you first have to gain the knowledge, do some R&D and then migrate

Sticking with forms authentication:

Pros:

  • you already have it and you just enable it for active clients

Cons:

  • forms authentication is not really "an authentication protocol". This means there is no obvious way to easily integrate with external authentication providers/consumers

Upvotes: 2

Related Questions