Notifications
Clear all
Topic starter
12/06/2026 12:07 am
TL;DR: Nook’s authorization case study shows how separating roles and permissions from application code let a six-person team onboard business users, limit sensitive financial visibility, and scale approvals across AP and AR workflows while keeping control with non-developers, according to Cerbos. The deeper lesson is that authorization becomes a product governance problem, not a framework convenience problem.
NHIMG editorial — based on content published by Cerbos: Nook’s authorization case study
By the numbers:
- One developer got 95% of the authorization work done in about 6 weeks.
Questions worth separating out
Q: How should teams separate authorization from application code in business apps?
A: Teams should move access rules into a centralized policy layer and keep the application focused on business logic.
Q: Why do fine-grained roles matter in finance and AP workflows?
A: Finance workflows mix owners, approvers, accountants, and operational reviewers, each with different responsibilities and data needs.
Q: What do organisations get wrong about authorization in early-stage products?
A: They often treat authorization as something to add later or embed directly in framework code.
Practitioner guidance
- Separate authorization from the application codebase Place role and permission logic in a centralized policy layer so access changes can be reviewed and updated without editing endpoint code.
- Model distinct business roles before onboarding new users Define separate entitlements for owners, finance staff, accountants, payroll teams, and operations reviewers before expanding access.
- Give business owners policy visibility without giving them code access Ensure non-developers can inspect and help shape access rules through policy tooling while engineering owns deployment and test integrity.
What's in the full article
Cerbos' full case study covers the operational detail this post intentionally leaves for the source:
- The exact policy design choices used to separate payment approval, invoice visibility, and payroll access.
- The implementation notes on converting endpoint methods into Cerbos actions for production use.
- The SQL authorization edge case that required extra engineering work.
- The day-to-day release-cycle handling of policy and test updates after implementation.
👉 Read Cerbos' case study on centralized authorization for Nook →
Permissions outside the codebase: what it means for scaling access?
Explore further
12/06/2026 9:10 am
Separation of permissions from code is now an identity governance requirement, not an architecture preference. When access rules stay embedded in application code, the organisation makes every role change a software change and every business exception a developer dependency. That creates avoidable delay, weakens auditability, and pushes governance decisions into places business owners cannot inspect. The implication is straightforward: permission ownership has to be treated as a first-class governance domain, not a byproduct of backend implementation.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How do centralized permissions help with scaling access governance?
A: Centralized permissions make it possible to add new user types, evolve approval flows, and keep sensitive data boundaries consistent as the product grows. They also reduce the risk that access logic fragments across endpoints, services, or developer-owned libraries. For governance teams, that consistency is what makes reviews and policy changes manageable.
👉 Read our full editorial: Separation of permissions from code is the real scaling test
