{"head":{"title":"What Is RBAC (Role-Based Access Control)? | OceanLab","description":"RBAC gives permissions to roles, then assigns roles to people, instead of granting rights user by user. How it works, an example and the usual mistakes.","canonical":"https://oceanlab.in/glossary/rbac"},"crumbs":[{"name":"Home","path":"/"},{"name":"Glossary","path":"/glossary"},{"name":"RBAC","path":"/glossary/rbac"}],"slug":"rbac","term":"RBAC (role-based access control)","aka":["role-based access control"],"category":"Identity and security","short":"An access model where permissions are attached to roles, and people get access by being given a role.","body":[["In RBAC you define roles such as viewer, editor, billing admin and owner. Each role carries a set of permissions, like view invoices or invite users. A person can do something only if one of their roles allows it. NIST published a standard RBAC model, later adopted as ANSI/INCITS 359."],["When rules depend on the data itself, such as a manager seeing only their own team, RBAC is often combined with attribute-based checks. Many products use roles for the broad strokes and per-record rules for the rest."]],"why":["Enterprise customers expect to control who can see and change what, and auditors check that access matches job need. RBAC keeps that manageable: change a role once instead of editing hundreds of users. It also underpins controls like ",{"href":"/glossary/maker-checker","text":"maker-checker"},", where the person who approves must hold a different role."],"example":["In a finance app, clerks can create payments, approvers can approve them and auditors can only read. When a clerk is promoted, the admin swaps one role and every permission changes with it, which also shows up in the ",{"href":"/glossary/audit-log","text":"audit log"},"."],"inBuild":["We check permissions on the server for every action, in one shared policy layer, never only by hiding buttons in the UI. Roles and their permissions are data, so customers can be given custom roles later without a code change."],"mistakes":[["Checking roles only in the front end, so the API still accepts the call."],["Hard-coding role names across the codebase, which makes new roles a big change."],["Role explosion: a new role for every special case until nobody knows what each one does."]],"related":[{"href":"/glossary/audit-log","label":"Audit log","detail":"A record of who did what in a system, when and from where, kept so actions can be traced later."},{"href":"/glossary/sso","label":"SSO (single sign-on)","detail":"One login, managed by an identity provider, that gives a person access to many separate apps."},{"href":"/glossary/maker-checker","label":"Maker-checker (four-eyes principle)","detail":"A control where one person makes a change and a different person must approve it before it takes effect."},{"href":"/glossary/multi-tenancy","label":"Multi-tenancy","detail":"One running copy of a software product serving many customers, called tenants, with each tenant's data kept apart."},{"href":"/glossary/oauth","label":"OAuth 2.0","detail":"A standard that lets an app get limited access to a user's account on another service, without ever seeing their password."}],"tools":[{"href":"/tools/soc-2-checklist","label":"SOC 2 checklist","detail":"Free tool"}],"links":[{"href":"/compliance/soc-2","label":"SOC 2 guide","detail":"The controls behind a SOC 2 report."}],"sources":[{"title":"NIST, Role Based Access Control project (ANSI/INCITS 359)","url":"https://csrc.nist.gov/projects/role-based-access-control","checkedAt":"2026-10-25"}],"legal":false,"updatedAt":"2026-10-25"}