[TriNetra]

Glad you asked! I'd incurrage to go through this [0] guide, or watch [1] video. But briefly: ASP.NET Core policy authorization works on full trust mode when it comes to the data sent by the callers. This means unless you write code to authorize access to resources, users will have access to everything. And to authorize a single resource mentioned in an API operation, you have to write lot of code including a requirement definition, an authorization handler, and invocation of the authorizationService from the action body. Just imagine doing this for multiple resources in an operation and doing it for hundreds of API operations. All this is hard-coded which is vulnerable to omission and manual mistakes, not to mention the time you spend on writing/maintaining such code.

On the other hand, ASPSecurityKit works on zero-trust principle, which means by default users have access to nothing, and gain access to only those resources you explicitly grant. The best part is that you don't have to write any code for this protection in most cases; your code remains crisp and clean throughout.

0: https://aspsecuritykit.net/guides/aspnet-policy-authorizatio...

1: https://youtu.be/t-3bhDKJvlY

[lukevp]

Agreed that open by default is bad once you start building APIs, but it’s pretty easy to register a default policy to require authorization and override it with AllowAnonymous or other policies as required.

[TriNetra]

The focus here is on resource authorization, and for that there's no default in policy authorization. You've to write code in action body, capturing each id input from the request object, and authorizing it via the default authService explicitly. You can imagine that it's easy to miss out on some property – say by a new developer down the line while adding a new property to the request model. And if that happens, a whole for the intruder becomes available to pass any id, and leak data of your users.

Additionally, the problems of your auth code mixing with action body, and hard-coded checks of roles/privileges and extensive testing for changes are always there.

While with ASPSecurityKit's ADA, it's always unobtrusive and kinda automated authorization once you've setup the convention in the beginning of the project (which is fairly simple, one line of code usually as shown in the video). If you forget something, the default is with ADA to deny access (zero-trust), and not pass-through.

HOpe it made sense - happy to give more examples. You can also go through the guide https://aspsecuritykit.net/guides/aspnet-policy-authorizatio...

[abgr-y]

Agreed but i guess the point with aspsecuritykit is that it requires authorization by default and one need not do any additional setup for that