It seems like all of these checks are in the wrong class. This was previously the responsibility of the evaluator - to evaluate the success of the policies. Now that code has moved to this class. I think this code belongs in the Authorization Service, not this class.

What checks? if (policyNames?.Count == 1) ? It's just a small optimization. Authorization Service authorizes a single policy. I see no code there that can be moved inside Authorization Service.

This was previously the responsibility of the evaluator - to evaluate the success of the policies.

I know. In case of the custom evaluator, the client had to write more code to create and fill AuthorizationContext, iterating through all tasks, etc. I changed the architecture so that it was more flexible. In many ways, it corresponds to how this is done in ASP.NET Core. I understand that the initial design was taken from there.

It is looping over each of the policies and building up the validation result for each policy, which was previously the responsibility of the the Authorization framework. That responsibility was moved to this GraphQL class instead. This GraphQL class should call into the Authorization framework, it should not BE the framework.

So AuthorizationValidationRule is not a framework class in your opinion. Right? Does this suit you if I will simply move all three dependences from rule ctor in one new dependency (evaluator) as it was before? Of cource I'll add then DafaultAuthorizationEvaluator with these three dependencies in its ctor.

This GraphQL class should call into the Authorization framework, it should not BE the framework.

And just a note - I thought that since the AuthorizationValidationRule class is located in the GraphQL.Authorization project among other classes, then it is an integral part of this framework. I do not understand what rule you use to decide which classes are included in the framework and what is not.

I think this code can also be moved to the Authorization Service. That would remove both the IClaimsPrincipalAccessor and the IAuthorizationPolicyProvider out of this validation rule class, which was intended to be a simple wrapper around the authorization framework.

Authorization Service uses provided context and does not create it. This is the whole point. Otherwise, it will solve several tasks.

which was intended to be a simple wrapper around the authorization framework.

Now it not much more difficult:

new AuthorizationValidationRule(new DefaultAuthorizationService(), new DefaultClaimsPrincipalAccessor(), new DefaultAuthorizationPolicyProvider(Settings));

I agree that dependencies appeared but it rather says that they were before, only in implicit form and they could not be replaced independent of each other. Now it can. Authorization evaluator tasks before these changes:

1. Create auth context.
2. Pick policy by name from settings.
3. Authorize policy.
4. Iterate over all policies.
5. Create AuthorizationResult.

Too much.

Yes, that was the entire purpose of the Evaluator class, to handle all of those things so the Validation Rule, which is a GraphQL Concept, does not have to. The previous design you could use this Authorization framework in any application, it had no direct GraphQL dependencies besides the Validation Rule. The Validation Rule was just the entry point to the Authorization framework. This moves a lot of the actual Authorization logic into the GraphQL class, which tightly couples it to the GraphQL framework. You can no longer use a single class outside of GraphQL to get the full Authorization Result, it is now dependent on the Validation Rule to handle evaluating policies.

The previous design you could use this Authorization framework in any application

But isn't it still possible to use Authorization framework in any application?

tightly couples it to the GraphQL framework

I look at it on the other side. Tightly coupling factor did not increase. It already has already been all this time inside the code. My changes made some dependencies explicit. Before that, they were hidden.