How do ABAC and RBAC differ, and when would you choose ABAC?

• A. ABAC uses attributes (such as department, clearance, time) to drive decisions, making it suitable for fine-grained, context-aware access control.
• B. ABAC uses roles to grant permissions, which is typical RBAC.
• C. ABAC relies on tokens to authenticate users, not relevant to access decisions.
• D. ABAC is always slower and less scalable than RBAC.

Answer: (A)

ABAC bases access decisions on attributes from the user, the resource, and the context, rather than on fixed roles. By evaluating attributes like user.department, user.clearance, resource.classification, and environmental factors such as time or location, you can express policies that grant or deny access in a fine-grained, context-aware way. This flexibility is why ABAC is a good fit when you need nuanced control across many resources and dynamic conditions, without enumerating every possible role.

Think of it as building policies that say “permit when these attributes satisfy these conditions,” which scales well in diverse environments. In contrast, RBAC maps permissions to a set of roles, which is simpler but can become rigid and harder to maintain as needs evolve. Tokens can carry attributes used in ABAC decisions, but authentication versus authorization are separate ideas. ABAC isn’t inherently slower or less scalable than RBAC; with a well-designed policy engine, it can perform efficiently and scale to complex access requirements.