MVC5 Authentication filters

Question

What is the difference between new Authentication and previous Authorization filters?. I don't see any difference. I always used: [Authorize(Roles = "Admin, User")]

When would you want to use Authentication filter? and when to use Authorization?

Can someone please explain the difference? Samples would be great. thanks

Answer 1

You can find an article here:

I’ve also created a similar post here:

Although the answer I got was great to clarify a few things, but I’m still a bit confused on how to use it but more with the expected behavior (as you’ll see if you read my post).

In a nutshell, the new Authentication filters are triggered before the old Authorization filters.

In addition, and from what I understand, authentication would be a great place to check if a user is authenticated on your website. In other words, did that user, at some point, gave me his credentials for me to look them up against a database. If the answer is yes, then great...continue.

If the answer is no, then the user is NOT authenticated which in turn, I should return an http status code 401 Unauthorized.

---

As for Authorization, again, my understanding is that the user is implicitly authenticated and he may or may not be Authorized to access a certain page or resource. If that’s the case, then I should return an http status code 403 Forbidden. And that is where the [Authorize] attribute comes into play.

---

Although this is what I understand, the behavior of both these filters is not working like I think they would work. Perhaps this is caused by my lack of understanding...

For example: The new Authentication filter does not seem to recognize (or take into account) the [AllowAnonymous] attribute. And the way I see it, it should.

On the other hand, the old [Authorize] attribute does recognize (and take into account) the [AllowAnonymous] attribute.

In the end, I’m not sure if this will help you or confuse you more, but I’m still in the process of playing around with them to fully grasp it.

Answer 2

Well the basic difference between authorization and authentication is that authorization is the process of checking that you are 'authorized' to do something or access something. And authentication is checking who you are in the first place, or checking that you are indeed the one that you say that you are (i.e. that you are 'authentic').

Authorization is typically done by looking at your user roles (linked to your identity) and if any of them are satisfactory for the accessed functionality. Authentication is typically done by checking that your password matches the one stored (ideally in encrypted form) with your user name. E.g. that your credentials are correct. This of course relies on the assumption that your password is secret, so only you know your password.

However extended authentication scenarios are also possible, like a Facebook server saying that you are indeed the person with the given username (as you logged in with them previously). A mechanism known as Single Sign On (SSO). It is these different scenarios that can be implemented via the (possibly custom) authentication filters.

So far I have only given some definitions. But to sum up; in principle Authentication will NOT look at your user roles, while Authorization will ONLY look at your user roles. Also note that authorization can only take place after authentication has been done. Which is why the authentication filters take precedence over the authorization filters. And it also shows that you can use both attributes on the same method, so it's not typically a choice between either authentication OR authorization, but you can use both!

The plain [Authorized] attribute without any Roles= attribute specified is probably most confusing, as this just checks that you are logged on, e.g. are authenticated. So that can be seen as authentication. But authentication actually already happened prior to that. Authentication filters are only now added per MVC5 because before authentication was almost always done via one technique: the ASP.NET auth cookie that you get after (Membership) log in. Now that oAuth and other SSO login methods have become so mainstream the new auth filters provide hooks to more easily implement alternatives. Like: 'set the auth cookie if Facebook says it's okay' :).