Why does '[RequireScope]' check non-user token scopes?

[julealgon]

I came upon a scenario where I need to have the same controller action accessible to users, as well as to daemon applications. At this point was when I realized my current setup that had a single [RequiresScope("access_as_user")] (from the default AAD Web Api project template) was insufficient: since scopes only make sense for user tokens, I needed a separate app role check for daemon access tokens.

A role check could be added using something like [Authorize(Roles = "access_as_application")], but then the issue is that both checks are attempted in sequence in an AND manner, meaning they will always fail: an user with scopes would fail the roles check, while a daemon with roles will fail the scopes check.

If scopes only ever make sense for user tokens, why does the authorization handler for ScopeAuthorizationRequirement try to validate the scopes regardless of token type? Wouldn't it make more sense to skip validation of scopes for a daemon-type token?

I'm aware that while scopes don't make sense for daemon tokens, roles can make sense for user tokens. So role checks should not be skipped for user tokens and I could probably never make the "2 attribute approach" work anyways but I figured I'd ask regarding [RequiresScopes] by itself.

Related:

• .NET 5.0 protected web API - verify scopes or app roles in a single action #1302
• [Documentation] How to verify scope or app role in the same controller action #963