Authentication, authorization and access control models: DAC, MAC, RBAC and ABAC compared

Most access-related incidents are not clever. Someone logged in who should not have been able to, or someone who logged in correctly could do far more than their job required. The first is an authentication failure, the second an authorization failure, and they are fixed in different places.

In part 5 we covered the cryptography that protects credentials. This part is about what happens around them: proving who someone is, deciding what they may do, and choosing a model for those decisions that still makes sense when the company is five times bigger.

Three separate questions

Access control is the set of policies and mechanisms that enforce authorization decisions. The goal is short to state and hard to achieve: the right people get the right access to the right resources, at the right time, and nothing more.

Authentication: proving identity

Factor types

Authentication factors fall into three categories:

• Something you know: password, PIN, security question.
• Something you have: phone with an authenticator app, hardware security key, smart card.
• Something you are: fingerprint, face, usually unlocking a device-bound key rather than being sent anywhere.

Multi-factor authentication (MFA) combines factors from different categories. A password and a security question are two things you know, which is not MFA.

Not all MFA is equal

For administrators, developers and anyone with access to production, payments or customer data, aim for phishing-resistant methods. For general users, any MFA is a large improvement over a password alone.

Sessions are part of authentication

After login, the session token is the credential. Stealing it skips the password and the MFA. Protect sessions with secure, HttpOnly cookies, reasonable lifetimes, rotation after login and privilege changes, and re-authentication before sensitive actions such as changing email, bank details or MFA settings.

Authorization: deciding what is allowed

Every authorization decision has the same shape: a subject (user or service) wants to perform an action on a resource, in some context. The access control model decides how that question is answered.

Discretionary access control (DAC)

The owner of a resource decides who else can access it. File permissions on a personal laptop and sharing a document with colleagues are DAC.

• Strength: flexible, natural for collaboration.
• Weakness: access spreads in ways nobody reviews; one owner's mistake exposes the resource.

Mandatory access control (MAC)

A central policy assigns labels to subjects and resources, and the system enforces rules between them. Users cannot override it. Military classification levels and SELinux policies are MAC.

• Strength: strong, consistent enforcement.
• Weakness: rigid and heavy to administer; rarely used directly in business applications.

Role-based access control (RBAC)

Permissions are grouped into roles, and users are assigned roles. "Support agent", "billing admin" and "read-only auditor" are roles.

// Laravel-style policy using roles
public function refund(User $user, Order $order): bool
{
    return $user->hasRole('billing_admin');
}

• Strength: easy to understand and review; maps to job functions.
• Weakness: "role explosion" when every exception becomes a new role, and roles cannot express conditions such as "only for their own region".

Attribute-based access control (ABAC)

Decisions are made by rules over attributes of the subject, resource, action and environment.

public function refund(User $user, Order $order): bool
{
    return $user->hasRole('support_agent')
        && $user->region === $order->region            // subject and resource attributes
        && $order->total <= 500                          // resource attribute
        && $order->created_at->greaterThan(now()->subDays(30));  // environment / time
}

• Strength: expresses fine-grained, contextual rules without new roles.
• Weakness: harder to reason about and audit; rules need tests.

Which one to use

Most applications end up with RBAC for coarse permissions and a few ABAC-style conditions for ownership and context. That is a reasonable default. The key is to put the decision in one place, such as a policy class or an authorization service, rather than scattering if statements through controllers.

Principles that matter more than the model

Least privilege

Give each user and service the minimum access needed for its task, and no more. In practice:

• New employees start with a baseline role and request extra access with a reason.
• Services get their own credentials with narrow permissions, never a shared admin key.
• Elevated access, such as production database writes, is granted for a limited time and logged.

Separation of duties

Critical actions need more than one person. The developer who writes a change should not be the only one who can approve and deploy it to production; the person who creates a supplier should not be the one who approves payments to it.

Deny by default

If no rule allows an action, it is denied. New endpoints should fail closed until someone writes the authorization rule.

Enforce on the server, at the data

Hiding a button in the user interface is not authorization. Every API call must check permission on the server, and queries should be scoped so that a user cannot fetch another tenant's records by changing an ID.

Access reviews

Access drifts. People change teams and keep old permissions, contractors leave, service accounts outlive the project that created them. A quarterly review fixes most of it:

1. Export who has which role in each critical system: source control, cloud, CI, production database, admin panel, payment provider.
2. Send each manager the list for their team and ask them to confirm or remove.
3. Remove anything unconfirmed after a deadline.
4. List service accounts and API keys, with their owner and last use; disable those unused for 90 days.

Connecting systems to single sign-on with automated offboarding makes the leaver part almost automatic.

Key takeaways

• Authentication proves identity; authorization decides what that identity may do. They fail and are fixed differently.
• MFA means factors from different categories; FIDO2 keys and passkeys resist phishing, SMS and TOTP do not.
• DAC, MAC, RBAC and ABAC answer "who decides access"; most apps combine RBAC with attribute conditions.
• Least privilege, separation of duties and deny by default matter more than the choice of model.
• Authorization belongs on the server and in data queries, and access needs regular review.

The next part looks at network security controls: firewalls, IDS and IPS, VPNs and proxies.

References

• NIST SP 800-162, Guide to Attribute Based Access Control: https://csrc.nist.gov/pubs/sp/800/162/upd2/final
• NIST RBAC project: https://csrc.nist.gov/projects/role-based-access-control
• OWASP Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
• OWASP Multifactor Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html
• FIDO Alliance, Passkeys: https://fidoalliance.org/passkeys/