These "why X is hard" articles seem to be based heavily on one's experience. My immediate thought about authorization's complexities was that the rules tend to be poorly defined and changing: users usually want to have full access to everything, non-users tend to restrict them too much, and then there are some odd exceptions like users being between roles, or belonging to a role but with some exceptions.
This article lists complexity of enforcement, mentioning that it's done in many places. That's not quite my experience: it's indeed hard to do and easy to mess up doing that way. Given that most of the projects where authorization is needed are about database access/interfaces, a DBMS itself is a good candidate for security policy enforcement in a single place.
The next point is decision architecture, talking about lack of database access when an authorization-related decision needs to be made, but it won't arise with authorization happening in the database. The article mentions that it becomes a problem if you try to use authorization in multiple microservices or something like that, but pretty sure that in most cases it is unnecessary.
The last point, modelling, is the closest to how I'd answer the title question. Oso claims to solve it by introducing a declarative policy language, which is what DBMSes provide too; PostgreSQL, for instance, even allows rather advanced (arbitrary SQL queries) programming of policies (via row security policies). Still doesn't quite solve the issue of requirements being a vague and changing mess.
For the first two points, I'd rather call it "how to make authorization hard".
Edit: To be fair, the third problem is man-made too, and could be avoided; it's just rarely under the programmer's control, unlike the other two.
Interesting - so essentially you are saying to push all authorization logic into the DB? What if your app also needs to access other services (e.g. a message queue, S3 etc)?
With multiple data sources requiring authorization, which don't support it on their own, it indeed makes sense to handle at least some of the authorization in the software accessing them all, and then it's indeed more complex. I just doubt it's commonly needed, to the point of listing it under things making authorization in general hard.
This article lists complexity of enforcement, mentioning that it's done in many places. That's not quite my experience: it's indeed hard to do and easy to mess up doing that way. Given that most of the projects where authorization is needed are about database access/interfaces, a DBMS itself is a good candidate for security policy enforcement in a single place.
The next point is decision architecture, talking about lack of database access when an authorization-related decision needs to be made, but it won't arise with authorization happening in the database. The article mentions that it becomes a problem if you try to use authorization in multiple microservices or something like that, but pretty sure that in most cases it is unnecessary.
The last point, modelling, is the closest to how I'd answer the title question. Oso claims to solve it by introducing a declarative policy language, which is what DBMSes provide too; PostgreSQL, for instance, even allows rather advanced (arbitrary SQL queries) programming of policies (via row security policies). Still doesn't quite solve the issue of requirements being a vague and changing mess.
For the first two points, I'd rather call it "how to make authorization hard".
Edit: To be fair, the third problem is man-made too, and could be avoided; it's just rarely under the programmer's control, unlike the other two.