[Authorize(AuthenticationSchemes = Custom)] on Controller takes precedence over [AllowAnonymous] on Action

[ghost]

I have created a new custom AuthenticationHandler. On the controller I have put the attribute Authorize with this new Authentication Scheme. On the action I have put AllowAnonymous. When I call the action, the AuthenticationHandler.HandleAuthenticateAsync gets called first, it will fail with a AuthenticateResult.Fail result, but then the action will get called. I would expect the AllowAnonymous to override the Authorize of the controller.

[Authorize(AuthenticationSchemes = TokenAuthenticationDefaults.AuthenticationScheme)]    
public class ApiController : Controller
{

[AllowAnonymous]
[Route("api/login")]
[HttpGet]
public async Task<IActionResult> Login(LoginModel model)       
{}

}      

[ghost]

I just checked the source (Microsoft.AspNetCore.Mvc.Authorization,AuthorizeFilter) and it seems this is the desired behaviour.

 var policyEvaluator = context.HttpContext.RequestServices.GetRequiredService<IPolicyEvaluator>();

    var authenticateResult = await policyEvaluator.AuthenticateAsync(effectivePolicy, context.HttpContext);

    // Allow Anonymous skips all authorization
    if (context.Filters.Any(item => item is IAllowAnonymousFilter))
    {
        return;
    }

So the authentication happens whenever there is a Authorize attribute, and it happens before a check for AllowAnonymous. It would be nice if there was a attribute "NoAuthentication"

[swlasse]

@bogdan-s I stumbled upon this the other day, and was a bit surprised to see the same behavior as you. Do you know why this has been closed? It sure looks like a behavior that is worth reconsidering - using the AllowAnonymous attribute as a short-circuit and ignore all other authorization rules seems fair, but I might be missing something?

[ghost]

@swlasse I will reopen it for you. I didn't want to spend too much time on this, since they've designed it like this and it was not blocking me.

[swlasse]

Thanks @bogdan-s. It might very well be that it is designed like this on purpose, but in any case, I think it is good observation which deserves some attention. Would be great to understand why it is like this.

[muratg]

@swlasse Yes, this is by design.

[swlasse]

@muratg Thanks for confirming this. It would be great to understand why it is like this though. Why not short-circuit immediately without invoking any AuthenticationHandlers?

[Tratcher]

@HaoK the description here is the opposite of what we discussed, AllowAnonymous isn't overriding Authorize like it's supposed to. More specifically it's not overriding it soon enough. Why isn't the anonymous check first?

[muratg]

@Tratcher isn't this what we want?

You don't want to accidentally allow anonymous access to a random API method if you have Authorize at the class level IMO.

Opposite sounds fine to me... i.e. class is anonymous, and you add additional Authorize requirements at the method level.

[Tratcher]

AllowAnonymous has always trumped, but what they bring up here is that Authorize runs anyways and then gets discarded. Why does Authorize run at all?

[HaoK]

Oh this is the bug where multiple filters were running, that's why we added the new flag that was turned on by default in 2.1, CombineAuthorizeFilters

aspnet/Mvc#7129

[Eilon]

This issue should be addressed in 2.1 based on the previous comment.

[swlasse]

I might be missing something here, but I am curious to know what is the answer to what @Tratcher points out?

AllowAnonymous has always trumped, but what they bring up here is that Authorize runs anyways and then gets discarded. Why does Authorize run at all?

I see there is pull request referenced, but I am not entirely sure how that relates to this?