I think resources based access control is something beyond a role based access control. With roles, a user is bound to a permanent identification. it is very limiting when you work in environment where one account is shared across multiple applications.

With resources based access control, a user have permission to resources based on specific specific target. For example, a user can be owner of one store and a simple manager of a different store without being globally labelled a manager or a store owner.

Another exemple is a aws, your account doesn't directly have access to all features in services, you create a IAM user and give a specific permission on a specific resources to that IAM user. It makes it easier to introduce new authorities and permissions without touching the core of your auth. Instead of (user , user role) you have (user, target, permissions of user in the target).

It makes it also really easy to have real-time access control. Still, case of a store manager and owner, a manager can have access to create product now for example, and on the next request no longer have access to it, while still have access to other permissions in the store, all that without needing to affect the global identify of the user in any way.

It's important to mention that this can lead to larger queries for permissions. For exemple, instead of just checking if a user has a specific role, you need to check if a user a a specific permission on a specific target. But with a good caching layer, it's way more powerful in every single way compared to role based access control.