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.
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.
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...