Understanding Common Access Control Models: ACL, DAC, MAC, ABAC, and RBAC

When building OAuth2.0 or social‑login features, many developers encounter questions about permission system design; this article answers those by introducing five mainstream access‑control models.

ACL Model: Access Control List

ACL is the earliest and simplest model that controls access based on objects; each object has a list of subjects and allowed actions. Example: an article’s edit list contains user A, allowing A to edit. Drawback: maintenance becomes costly when many subjects exist.

DAC Model: Discretionary Access Control

DAC extends ACL by allowing subjects to grant their own permissions to other subjects, enabling permission propagation. Example: typical file‑system permissions in Linux, UNIX, Windows NT. Drawback: permissions become scattered and can lead to accidental data leaks.

MAC Model: Mandatory Access Control

MAC enforces a two‑way label check: both subject and object carry security labels, and access is granted only when the labels match. Example: military ranks versus document classification levels. Drawback: overly strict, high implementation effort, and low flexibility.

ABAC Model: Attribute‑Based Access Control

ABAC decides access by evaluating dynamic attributes of subjects, objects, environment, and operations. Attributes include user age, document type, time windows, etc. Example: time‑restricted exam access for departments. Drawback: complex rules, difficult to understand relationships, and limited adoption.

RBAC Model: Role‑Based Access Control

RBAC links users to roles, and roles to permissions. Core elements are users, roles, and permissions. Advantages include easier role assignment, flexible authorization, and minimal granularity. The model can be refined into RBAC0, RBAC1, RBAC2, and RBAC3, adding role hierarchies, constraints, and combined features.

RBAC0

Basic many‑to‑many relationship between users‑roles and roles‑permissions.

RBAC1

Introduces role hierarchies, allowing child roles to inherit parent permissions.

RBAC2

Adds constraints such as mutually exclusive roles and role cardinality limits.

RBAC3

Combines RBAC0‑RBAC2 features for a comprehensive model.

Practical Application in Real Systems

Permission management consists of three parts: user management, role management, and permission management. User management aligns with organizational or business structures; role management should reflect real‑world job functions and may include automatic base roles, temporary roles with expiration, virtual roles, and whitelist/blacklist mechanisms. Permission management covers page/menu visibility, operation (CRUD) rights, and data-level controls (row/column permissions), often requiring both front‑end hiding and back‑end enforcement.

Key Practices

Super‑admin accounts should be hidden after initial configuration.

Handle mutually exclusive roles by prompting administrators to remove conflicting roles first.

Keep the permission system simple and clear to avoid future complexity.

Provide a “no‑access” hint page instead of a generic 404.