What are RBAC and ABAC?

RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control) are two ways to answer “is this user allowed to do X?”

RBAC

Users are assigned roles. Roles have a fixed set of permissions.

User "Jane" has role "Admin"
Role "Admin" has permission "delete_post"
→ Jane can delete posts

Simple, readable, scales to 80% of apps. Four or five named roles (Owner, Admin, Member, Viewer) cover most B2B SaaS.

ABAC

Permissions depend on attributes of the subject, object, or environment, not just the role.

User "Jane" has role "Editor"
Post "P" has attribute authorId = "Jane.id"
→ Editors can edit posts they authored → allowed

Necessary when rules involve object context — “editors can edit posts they wrote, but not others’”.

When to use which

Start with RBAC. When the rules start requiring “X but only if Y,” introduce ABAC for those specific cases. Don’t leap to full ABAC on day one — the rule complexity explodes.

Tooling

• RBAC: a role column + a permissions module in your codebase
• ABAC: a policy engine like Oso, OpenFGA, or Cedar for complex rules

Don’t invent your own policy language. Use the proven engines.

See the full auth glossary for related terms.