Implementing Authentication and role based authorization in ASP.NET MVC web API service and MVC client architecture

Question

I'm having hard time in deciding an approach while implementing Authentication/Authorization scenario for my Web API (Service) - MVC (client) architecture project. Even though i have implemented Custom token based authentication in Web API project, I'm finding it hard where exactly i should implement the authorization (In Client or in API itself).

---

Architecture Overview :

• Projects Solution -
  |
  | __ ASP.NET Web API based REST service (Independently hosted on IIS at M/C 1)
  |
  | __ ASP.NET MVC based Client (independently hosted on IIS at M/C 2 Consuming REST service)
  |
  | __ Smart phone client Application (Consuming the REST service)

Already implemented authentication :

• Token based authentication in Web API (using Message Handler) - Which generates SHA1 encripted token for authenticated user which needs to be a part of every http request header for authentication.
  (Token = User Name + User IP)

• SSL protected HTTP request. (Again, Using Message Handler)

Current problems :

1. At what layer the authorization should be implemented?
2. How does user role should be persisted at client? Using Cookies? or Adding role information to Token itself ( Which might add overhead for API to decrypt the information and extra DB calls to retrieve permissions associated with that role)
3. How the Authentication Token should be persisted with Client session?
4. Since, my application is SPA MVC application, What is the best way to include the Authentication token as a part of every AJAX call i make to API?

---

I hope, I'm not doing things wrong while taking the whole authentication/authorization concept in to consideration. Thus, I'll appreciate any alternate approach/suggestion.

Answer 1

First of all I think it's never a good idea to invent your own authentication mechanism.

To answer your current problems:

1 Generally spoken you always want to secure your Api using authentication since it's the place where you access your data. Your client (MVC App/Smartphone) should authorize itself to get access to your Api.

2 & 3 Since you are using a REST Api I would suggest to keep your Api stateless, with other words, don't keep any session information. Just include the role data you need in your Token. You could use for example an JSON Web Token.

4 I would always use the authorization header to send authorization data. In your DelegatingHandler (Note the difference MessageHandler MVC, DelegatingHander HTTP) you can simpy retrieve the header.

protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
 {
    var authorizationHeader = request.Headers.Authorization;
    // Your authorization logic.

    return base.SendAsync(request, cancellationToken);
 }

For more info on how to include the authorization header in an ajax call please see: How to use Basic Auth with jQuery and AJAX?

Extra info:

If I were you I would also take a look at Thinktecture's Identity Server: https://github.com/thinktecture/Thinktecture.IdentityServer.v2

And maybe this answer about REST Service Authentication will help you as well: REST service authentication

Answer 2

Why create an entire token system (unless you're using some kind of federated security) you have forms authentication and cookies, once the cookie is set and returned the browser will send the cookie with any AJAX requests made by your SPA.