Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free.

I have an MVC app. It also uses services exposed by Web API controller.

Hosting environment for both MVC and Web API is IIS. In IIS authentication mode set is anonymous.

HttpModule is used to set User's identity and role to Thread and HttpContext object both.

Doing all that MVC controllers are being called properly but Web API controllers return 401 unauthorized error.

appropriate authorize attribute are used in both controllers.

Below is the code used user to set user to thread and context object.

var principal = new GenericPrincipal(new GenericIdentity(userName), roles);
                // contextBase.User = principal;
                HttpContext.Current.User = principal;
                Thread.CurrentPrincipal = principal;
share|improve this question

1 Answer 1

up vote 3 down vote accepted

Web Api is REST-based. Among other things, REST is stateless, meaning no concept of a session. Authentication in MVC is handled via sessions, so simply authenticating in MVC side of the app does nothing for the Web Api side.

Each Web Api request must have all the information necessary to fulfill that request, which includes any applicable authentication/authorization. Typically with an API, this is handled by passing an authentication token in the request headers, but there's many way you can authorize an API request. I'd recommend just searching for something like "web api authentication" and reading a bit.

Long and short is that authorizing a web api endpoint requires a different and separate process from authenticating with your MVC site.

share|improve this answer
    
are you saying i need to have different authentication mechanisms to WEB API controllers? –  Sam Feb 23 at 20:46
    
Not correct. In ASP.NET "sessions" are separated from "authentication" so that you can enable one without enabling the other, but they're both session-based, in general sense (which is what I meant). Even then, not all MVC auth is forms auth-based. MVC 5 uses Identity by default which it totally separate and parallel to forms auth. Whether or not cookies are involve is also a separate concept and configurable on its own (though cookieless sessions/auth is deprecated at this point). –  Chris Pratt Feb 23 at 20:51
    
@Sam: Yes. That's exactly what I'm saying. They can both reference the same user persistence store and even employ the same infrastructure (Identity, in the newest public releases), but authenticating with your MVC site has no effect at all on your authenticated state with your Web Api and vice versa. They use entirely different methods of determining what makes a request "authorized" or not. –  Chris Pratt Feb 23 at 20:53
    
Thanks, I also found articles which explain we can use HttpModule for authenticating/authorization WebAPI's. These modules can also be used for MVC controllers. is there a way in which i can use same HttpModule for both since my application uses IIS as hosting environment? –  Sam Feb 23 at 23:37
1  
Again, it's a difference in how REST APIs work versus a traditional website. With a REST endpoint, the authentication token or whatever has to be passed with each request, as each is a unique thing, unaffected by anything that has happened before or since. With a traditional website, sessions are employed to persist the authentication status between requests. No one solution will work for both. –  Chris Pratt Feb 24 at 15:40

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.