By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account ✔️ Resolution: Won't Fix Resolved because we decided not to change the behavior reported in this issue. investigate Status: Resolved

Unauthorized access returns 403 instead 401

After the migration to .net 6, our unit tests have identified that the unauthorized access, using the AuthorizationAttribute and identity role claims, returns the http status 403 (forbidden) instead of 401 (unauthorized) as with .net 5.
It’s a breaking change, because many clients could not manage the unexpected result, and it seems undocumented .

To Reproduce

The repro project is attached as a .zip file. WebApplication1.zip

Just changing the target framework, from 5 to 6 and vice versa, the http result code changes.

Further technical details

ASP.NET Core version

@maurik77 can you upload your repro app to a github repo, we generally don't open zip files

Of course, but I suggest you to change the instructions that appear when you open an issue.

You can find it here: https://github.com/Maurik77/RepoBugs

Needs: Author Feedback The author of this issue needs to respond in order for us to continue investigating this issue. label Dec 3, 2021

Hi @maurik77 . We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

Hi @HaoK ,

After downloading the repo the project is set to net6.0 (RepoBugs\WebApplication1.csproj)

Run the project

Execute: curl https://localhost:5001/weatherforecast -v

You can verify that the app replies with http status 403 (Forbidden)

Change the target framework to net5.0

Run again the project

Execute: curl https://localhost:5001/weatherforecast -v

You can verify that the app replies with http status 401 (Unauthorized)

Needs: Attention 👋 This issue needs the attention of a contributor, typically because the OP has provided an update. and removed Needs: Author Feedback The author of this issue needs to respond in order for us to continue investigating this issue. labels Dec 4, 2021 asp.net .net 6: Unauthorized access returns 403 instead 401 asp.net .net 6: Unauthorized access returns 403 instead of 401 Dec 6, 2021

Thanks, I do see what you are seeing, its strange that this was a 401 in 5.0, as the correct behavior is 403 and we have a unit test that's been there since 5.0 too https://github.com/dotnet/aspnetcore/blob/release/5.0/src/Security/Authorization/test/AuthorizationMiddlewareTests.cs#L372

I'll try to see where the difference is

Okay I see the issue, in your auth handler, you are creating an identity that is not considered authenticated since you don't specify an authentication type, this is line: https://github.com/Maurik77/RepoBugs/blob/main/HermodrAuthenticationHandler.cs#L29

But the authorize attribute has an implicit check where we don't consider the identity authenticated for purposes of authorization if IsAuthenticated is false

You can verify this by checking identity.IsAuthenticated, you can pass in anything like new ClaimsIdentity("foo"); which will make the behavior be a 403 as expected.

I'll try to track down what side effects might have changed to cause this minor difference in behavior

Okay, thank you for the analysis, the problem ca be fixed, but anyway I suggest to describe the different behaviour in the
Api Diff Doc or some other official documentation because the upgrade can lead to an unexpected result.

Needs: Attention 👋 This issue needs the attention of a contributor, typically because the OP has provided an update. labels Dec 8, 2021

Thanks for contacting us.
We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here .

Okay, I think I found the introduction of this behavior/breaking change, as this was the only change that seems related to IsAuthenticated, was this change which now does some caching around the default authenticate result based on whether the user identity is authenticated:

https://github.com/dotnet/aspnetcore/blame/release/6.0/src/Security/Authorization/Policy/src/PolicyEvaluator.cs#L73

cc @Tratcher @blowdart @BrennanConroy

clearing milestone so this is visible in triage

Discussed this in triage, since the subtle change of behavior is in a scenario which isn't really useable in practice (auth handlers really should return principals that are IsAuthenticated=true, since they won't be useable otherwise, as that's the flag we use to determine if the identity is considered signed in). We don't plan on fixing this. The workaround for anyone that hits this, is to always set the authenticationType on their claims identities so IsAuthenticated will be true.

✔️ Resolution: Won't Fix Resolved because we decided not to change the behavior reported in this issue. label Dec 10, 2021 ✔️ Resolution: Won't Fix Resolved because we decided not to change the behavior reported in this issue. investigate Status: Resolved