Topic starter
11/06/2026 11:13 pm
TL;DR: Authorization is the control point that decides what users can do, according to Cerbos. It then compares RBAC, ABAC, DAC, MAC, and ReBAC as different ways to express access rules and context; the core issue is not the vocabulary of access control but whether policy, context, and review can keep pace with a growing system.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “What is authorization? Types, examples and definitions”.
Key questions
Q: Where does authorization fail in practice when applications keep growing?
A: Authorization fails when the access model cannot keep pace with new roles, attributes, relationships, and exceptions.
Q: How should teams choose between RBAC and ABAC for application authorization?
A: Use RBAC when access maps cleanly to business roles and the number of exceptions is low.
Q: What are the signs that authorization reviews are not working?
A: Signs include access that no longer matches job function, exceptions that never expire, policies that only a few engineers can explain, and review cycles that cannot keep up with changes in roles or ownership.
Practitioner guidance
- Define a single authorization decision boundary Separate policy evaluation from application logic so the app asks a consistent decision point instead of duplicating access rules in multiple services.
- Map each resource to the right control model Use RBAC for broad job-based access, ABAC for contextual decisions, ReBAC where relationships drive access, and MAC only where central classification is required.
- Review privilege changes on a fixed cadence Re-certify roles, attributes, and relationship-based grants whenever jobs, teams, or resource ownership change so stale access does not accumulate.
Bottom line: Authorization is the control boundary that determines whether secure access is actually enforceable inside an application.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/06/2026 7:48 am
Authorization is the real control boundary in secure apps. Authentication answers who entered, but authorization decides what that identity can actually do inside the system. That is why policy design, context evaluation, and review discipline matter more than the label attached to the access model. For practitioners, the boundary is not login success, it is whether every action is still governable at request time.
A question worth separating out:
Q: How should organisations govern custom authorization systems at scale?
A: Organisations should govern custom authorization like a core security service, with clear ownership, test coverage, change control, and periodic policy cleanup. If every new business exception becomes a permanent code path, the system becomes fragile and expensive to maintain. Scalable governance means reducing policy clutter before it turns into hidden privilege.
👉 Read our full editorial: Authorization design patterns define the real boundary of secure apps