Most authorization models are not chosen. They are inherited.
A product starts with a handful of roles because roles are what the framework offered. The roles multiply as the product grows. Five years later the security team is maintaining four hundred roles, half assigned to people who changed jobs twice. Every new feature ships with a role explosion attached.
That failure is usually diagnosed as bad hygiene. It is more often a modeling error. The organization is asking access questions that roles cannot answer, and no amount of role cleanup fixes a model mismatch.
The fix is to choose the model deliberately. There are three serious candidates: RBAC, ReBAC, and PBAC. The choice between them comes down to one discipline: write down the access questions your organization must answer, then pick the model whose native shape matches them.
Start with the questions, not the model
Every authorization system exists to answer questions. Who can see this record? Why does this contractor have write access? Can the auditor get a complete answer without a spreadsheet archaeology project?
Different questions have different shapes.
Some questions are about job function. Can analysts view reports? Those are role questions, and they are enumerable: a finite list of functions mapped to a finite list of permissions.
Some questions are about relationships. Can this user edit this document because she owns the folder it sits in? Can this manager see this account because his business unit services it? Those questions traverse a graph. The answer depends on how two specific things are connected, not on anyone's job title.
Some questions are about conditions. Can this trade be approved by someone who did not initiate it? Is this data accessible only during an active engagement, from a managed device? Those are policy questions: rules evaluated against context at decision time.
Force relationship questions into roles and you get the four-hundred-role tenant. Force policy questions into a relationship graph and you encode time and context where they do not belong. The model must match the question.
What each model is for
RBAC is the right model when access genuinely follows job function. Employees act in defined capacities, the capacities are stable, and the permission set for each capacity is knowable. Workforce applications live here. RBAC fails the moment "what is your job" stops predicting "what can you touch."
ReBAC is the right model when access follows structure: ownership, hierarchy, containment, delegation. Relationship-based access control stores who relates to what and answers questions by walking the graph. We implement ReBAC on Auth0 FGA, which is based on the OpenFGA specification. The model is expressed in relation tuples, which makes it readable:
document:roadmap#owner@user:diego
folder:plans#parent@document:roadmap
business_unit:acme-east#manager@user:harperCollaborative platforms, B2B applications with tenant hierarchies, and anything resembling a document tree are ReBAC problems.
PBAC is the right model when access depends on conditions rather than structure. Policy-based access control evaluates rules at decision time: separation of duties, time windows, device posture, data classification. Regulated workflows live here. PBAC carries the highest modeling overhead, so it earns its place where the conditions are the point, not as a default.
The models also compose. A real estate of applications usually needs RBAC for workforce capacity, ReBAC for resource structure, and PBAC for the regulated edges. The mistake is not mixing them. The mistake is answering one kind of question with the wrong kind of model.
A consolidation that made the choice visible
The clearest version of this decision we have worked on came from a Major MSP and Networking Service Provider. The company had grown by acquisition, and authorization had grown with it. Each product carried its own access logic. More than a hundred business units each had their own answer to who can manage what.
The defining access question was structural. A managed service provider's customers have their own customers. An operator at the MSP needed access to a tenant because of where that tenant sat in a service hierarchy, not because of the operator's job title. Hierarchies are relationships. Modeled as roles, that means a role per business unit per function, multiplied across products. That is the four-hundred-role tenant again, at MSP shape and MSP size.
Modeled as relationships, the hierarchy is just tuples: this business unit services that customer, this operator manages that business unit. The question "can this operator touch this tenant" becomes a graph walk that one model can answer the same way for every product.
The result was 100+ business units consolidated onto one Auth0 FGA authorization model. The consolidation worked because the model finally matched the question the business had been asking all along.
Choose early, and choose on paper first
The expensive version of this decision is the one you discover late. Authorization logic spreads into application code within months, and replatforming it after the fact means touching every product that embedded it.
The cheap version takes a working session and a document. Write the twenty access questions that matter to your security team, your auditors, and your product owners. Sort them: function, relationship, condition. The sorted list is the model decision, made visible before any tuple or policy is written.
Familiarity is not a criterion. The question you cannot answer today is the one that decides which model you need.