Notifications
Clear all
Topic starter
14/09/2026 10:09 am
TL;DR: Application permissions usually start as simple role checks, but SaaS growth, multi-tenancy, audit demands, and customer-defined roles quickly turn scattered authorization logic into infrastructure, according to PermitIO. The real failure is forcing authentication systems, JWTs, and request handlers to impersonate a policy engine, which creates latency, stale permissions, and audit blind spots.
NHIMG editorial — based on content published by PermitIO: Stop Rebuilding Permissions in Application Code
Questions worth separating out
A: Start with the most duplicated and change-heavy rules, then shift them into a centrally managed policy layer behind a policy decision point.
Q: Why do JWTs create problems for fine-grained authorization?
A: JWTs are good for carrying identity claims, but they are a poor place to store fast-changing authorization data.
Q: What are the signs that permissions logic has become architecture debt?
A: Common signs include access changes requiring deployments, inconsistent checks between frontend and backend, tangled role names, and explanations for denials that require reading multiple services.
Practitioner guidance
- Separate authentication from authorization architecture Keep the IdP responsible for identity proofing and token issuance, then route access decisions through a dedicated policy layer that understands tenant, resource, and context rules.
- Move critical decisions to local enforcement points Use a locally deployed PDP so the application can make low-latency allow or deny decisions without turning every request into a remote dependency.
- Replace hardcoded branches with explicit policy models Define permissions in product language, including principal, action, resource, tenant, ownership, and environment, then retire scattered handler conditionals as you migrate.
What's in the full article
PermitIO's full article covers the operational detail this post intentionally leaves for the source:
- A concrete before-and-after architecture for moving from scattered conditionals to a policy engine and local PDP.
- The practical migration sequence for replacing hardcoded permission branches without rewriting the entire product at once.
- Decision-log examples that show how allow and deny outcomes become audit evidence.
- The deeper discussion of how RBAC, ABAC, and relationship-based access evolve without reworking the control plane.
👉 Read PermitIO's analysis of why application permissions belong in infrastructure →
Fine-grained authorization in apps: when does RBAC become infrastructure?
Explore further
14/09/2026 10:10 am
Application authorization is a governance boundary, not a code pattern. Once access decisions depend on tenant context, resource state, and business rules, they are no longer simple role checks. They become a control plane problem, because the organisation now needs explainable, changeable, and auditable authorization separate from application delivery. The practitioner conclusion is to govern authorization as infrastructure, not as scattered business logic.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Another finding from the same survey shows that systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems.
A question worth separating out:
Q: Should organisations keep the IdP in the authorization path?
A: Yes, but only as an input source for identity data, not as the full permission system. The IdP should prove who the principal is, while a separate policy layer decides whether that principal can perform the action on the resource in context. That separation keeps authentication and authorization from being forced into one model.
👉 Read our full editorial: Application authorization is infrastructure, not scattered permission logic
