Is the Authorize attribute in ASP .NET MVC used for Authentication as well as Authorization?

Question

I'm reading up on ASP .NET MVC, and I just got to a section talking about the Authorize attribute. It's saying that the Authorize attribute is used to check that a user is authenticated against a Controller. Is this true? I know that the attribute is designed to be used for authorization purposes, but is it also a best practice to use this attribute for authentication?

If not, what is the best practice for verifying (not performing) authentication?

If so, why is it done this way? Am I missing something?

Answer 1

Authorize attribute can be used to check to see whether the user is logged in. It can also be used to check if the user is a member of a specific role and has a specific name.

It essentially does the same thing handled by <authorization> section in web.config when using Web forms.

It doesn't specify the authentication method. It's handled by <authentication> section in web.config just like Web forms.

EDIT (clarification about authentication and authorization):

Authentication is identity verification. That is, you check to see who the user is. This can be performed by checking a user name and password, checking your Windows authentication token, scanning retina, voice identification or whatever else.

Authorization is the act of limiting access to a specific resource to users that satisfy a certain criteria. To be able to authorize a user to a resource, you should know the rights the user have. To check that, you should know who the user is in the first place. So the user have to be authenticated.

Essentially an empty [Authorize] attribute does authorization, not authentication. It doesn't check who you are. It just checks if the one who you verified to be does have access to the resource or not. However, its authorization criteria is "anyone successfully authenticated." You can specify a different criteria. So, indeed it's doing authorization, not authentication.

Answer 2

Authentication and Authorization are two different concerns.

Authentication verifies that the user is who he says he is, almost always done in most web apps by verifying that he/she has some knowledge (like a password) that only he/she should know.

Authorization verifies that an authenticated user has the permissions to do something. Only administrators can access admin pages for instance.

Since we can get the roles of a person only once logged in, it is possible to use the Authorize attribute to test for authentication.

Take a look at this blog post and see how the author implements both a custom Authorize and Authentication attribute:

Securing your controller actions

You'll see that the Authorize attribute has to check for authentication, since only authenticated users can have a role.

Answer 3

Authorize does indeed check that the user is authenticated, otherwise it would not be able to determine the roles for the user or which user (other than the anonymous one) the current user is. That is, in order to be authorized, if anonymous access is not allowed, you have to be authenticated first. Below is the relevant snippet from the AuthorizeCore method in the RTM version (from http://www.codeplex.com/aspnet).

// This method must be thread-safe since it is called by the thread-safe OnCacheAuthorization() method.
protected virtual bool AuthorizeCore(HttpContextBase httpContext) {
    if (httpContext == null) {
        throw new ArgumentNullException("httpContext");
    }

    IPrincipal user = httpContext.User;
    if (!user.Identity.IsAuthenticated) {
        return false;
    }

    ...

If AuthorizeCore returns false in OnAuthorization, then the AuthorizationContext.Result is set to a new HttpUnauthorizedResult which will result in the user being redirected to the login page (in FormsAuthentication) or an error.

EDIT: After reading your comments to other answers, I would say that you ARE missing the point. Technically it is only doing authorization. One level of authorization, the minimum, is that you need to be authenticated to perform an action. You get this by not specifying any users or roles for the Authorize attribute. Any user or role is allowed, as long as it is authenticated. By specifying users and/or roles that act as filters you narrow down the scope of the action and the user needs not only be authenticated (so you can check the name/role membership), but also qualify based on the filter.