First: I researched to give a more reasoned answer and concluded that some people disagree at least on the details of what each thing is, it is not easy to find a formal definition, and this is less desirable, as long as what you use solves the problem well. I will put my conclusions.

The Access Control List is usually a generically used term without indicating the implementation of this. But some people confuse it with DAC (Discretionary Access Control) and I think this is what you're asking. I will answer the difference between DAC (which called ACL) and RBAC.

Who's in charge

For me the main difference is in what kind of resource is being given privilege. The DAC usually does this object by object. It can be a file, a message, an entry in a generic or specialized database, anything individual. RBAC usually gives access to more general resources, to generic entities that have multiple objects. Can be access pages of documents (but not the individual page), registered customers, device, etc.

In general can have some granularity of what you can do there like Create, Edit, Delete, view, download, approve, etc. Some general privileges only make sense in one of them. For example whether you can give ownership to someone is usually interesting in the DAC, but not necessarily in the RBAC.

Where is defined

Another important point is that RBAC is usually defined in code or if you have some flexibility can be controlled by a system administrator in general. The DAC is usually controlled by the owners of the objects.

In an operating system we usually see a DAC and since the user of that machine is usually the administrator the two get confused. And indeed in some cases some implementations are often hybrid, or at least lend features.

When RBAC starts to become more dynamic and less coded, when it can give privilege conditionally even by complex formulas it begins to turn into Attribute-Based Access Control (ABAC).

Paper

Role Based Access Control usually has 3 entities:

• role-which indicates a function that can be performed in the system
• user-who is associated with a person using the system
• privilege-which indicates something that can be done in the system (in general there is an association with a resource because otherwise it's just a permission), not least because permission is always given to a resource, so can change a customer is different from being able to change a product. Change is a generic privilege, and customer and product are resources, so the privilege is not unique, there are two, one for each resource. Some call it action.

Role is the focus of this modality.

In RBAC a new privilege is given to the role and all users who are associated with that role gain the privilege. Just like if you add a user you associate it with roles and it gains the privileges of these. And when you create a new role it tells you what privileges it will have and who are the users that are associated with it.

It becomes much easier to manage this way. But it's not all flowers because it has cases that a user should have a specific privilege that the people of a role should not have. The solution in a pure RBAC is to create a paper just for that.

Ultimately you could have as many roles as the combination of privileges is possible, i.e. you could have zillions of roles with a few existing privileges. Of course this would be in case exaggerated but it gives an idea that can complicate.

For the purposes of understanding and comparing to the DAC one can consider that the resource owner in these cases is the system administrator or the developer.

Done correctly is more scalable.

It can create a paradox. A role can be restricted to one action, another role to another. A person has the role of serving the customer, if he who is the least specialized and perhaps less reliable (often even outsourced) must have the privilege of the two previous roles to solve everything the customer needs it. If you do not do this the customer needs to talk to several people to solve their problems and will curse your company, if you do the restriction does not make sense. But of course this is a matter of organization.

ABAC

Some people say that if you have roles it's not ABAC, but I don't know, maybe just change the name because user or group can be considered the same thing. It has so much dissonant information that it becomes difficult to give a canonical information. And I do not know if it is important, it matters is to know that there are several mechanisms that can be used and meet your needs. I think someone creates a definition and then others start using something similar using the same term, do you know Bombril or Gilette? So strictly ABAC can have a clear definition, but people use the term for similar things.

ABAC usually considers contexts. Then it can even be given a privilege depending on where the person is accessing, the time, whether something has happened before, or any set parameter.

Some consider ABAC to be a framework (not necessarily a software framework).

Gift

No DAC has an owner specific to the individual resource that is who can give the privilege. Privilege can also be more granular.

This one does not usually have the role, so privileges are given directly to users. But some consider a hybrid system that allows you to have roles (roughly groups, although it is a slightly different concept) as if they were users a form of DAC, as long as it maintains the property characteristic of the resource.

Here the focus is the resource.

Hybrid

That is why it is common to adopt a hybrid system where you adopt the RBAC always and the DAC when it is very necessary (unfortunately this is not so well used and starts to turn mess). Even permission to use the DAC can be given according to RBAC, which decreases the possibility of failures in the organization.

Some people say that ABAC is precisely a hybrid form. Some put other characteristics and try to standardize a way of doing every process giving the chance for each one to have their own needs met.

Other points

Is not a clear requirement, but RBAC usually has more granularity in privileges. The DAC usually has the right of access and eventually write or something general too. RBAC usually has privileges that only make sense for one resource type, for example it can give a discount on a receivable security. But I don't see why the DAC can't have this, except for the fact that it has granularity on both sides create a pretty big burden to manage. Some will say that it begins to be an ABAC.

Roles usually have hierarchies, if we can use this name. So if a derived role gains a privilege the base role automatically gains it, which is the inverse of the hierarchy.

Advantages of each

In general RBAC is best where it potentially has a lot of users, or has a lot of user volatility, which is the vast majority of cases, and DAC adopted as a measure of flexibility. Only the DAC is used when you know that you will have very few users in any case.

RBAC is obviously a little harder to understand and operate for small volumes. The concept of user and privilege is intuitive by everyone, the concept of paper is not. And in many cases it is one more step to take (it is a indirect in the application), it brings advantages, but imposes a cost. But having some roles makes it easier to manage by giving stability and vision from who can what.

The DAC allows better privacy control and may not be so difficult to manage if there are roles as an add-on to the user system and you can group resources (some will say they are only groups and not roles).

The best is usually the hybrid, but in some cases to simplify it can have only RBAC, as long as it does not need great flexibility and the features are more general and not specific objects, although this also works). THE DAC it is usually better in a collaborative environment with many unstructured resources (files, tokens, messages, specific objects), but RBAC in such cases can still be useful.

You'll find more RBAC or ABAC in an ERP or something, and more DAC in an operating system or platform (a social network for example).

If you are an active OS user do an exercise: here use an RBAC, a DAC or an ABAC? How is Windows? Tip: it's not so simple.

As the DAC usually gives more work it is common for people to end up using it as an A/RBAC or loosening the control. Take this into account.

It seems that RBAC is the solution for an ERP, but think of cases that one division competes with another or has legislation that does not let the data of a particular product be improperly accessed because it has access to the products as a whole. Or a seller who can't see customer data that isn't his. Or even an employee see the salary of other people who are not your subordinates. It is not so simple to identify what is best. But the hybrid is often more powerful when it needs to.

I saw some people talking that R / ABAC works better with APIs, but I don't even see the link. For me API is not a resource, what is behind it is, API is the means of access but not the Access itself.

The specific ways to implement each is quite vast, you can use a lot of creativity.

Conclusion

As I always say, the concrete need is that defines which one to use. Understanding the concepts correctly and knowing how to analyze and define well the problem that has in front of you is that allows you to choose which is the best. You can cite examples like I did above to indicate a path, but you run the risk of deciding simplistically and trying to fit your case as if it were one of these examples and do the same.

Something complex cannot be understood as if it were a cake recipe. Unfortunately the people believe that this is possible, so there is more and more bad thing being developed.

It is always the commitment of the user that will make the control succeed. Both are difficult to keep consistent over time.

I disagree with some conclusions that I found out there, perhaps from different experience or because some of them were taken in the past when you did not know how to deal with certain situations, including mixing audit with access control that are very different concepts, connected, but independent.