Permissions outside the codebase: what it means for scaling access

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

View Full Forum →  |  NHI Foundation Course →