Laravel Authz Laravel Package

Product Decisions This Supports

• Build vs. buy for authorization. Keeps policy enforcement in-house under Apache-2.0 instead of licensing an external authorization service (Auth0 FGA, WorkOS FGA, Permit.io, Oso). The decision this package informs: do we pay per-MAU for entitlements, or own a policy engine and an admin surface?
• "Custom roles" as a roadmap feature. The single biggest product unlock here is letting workspace admins define their own roles and permissions without an engineering ticket. Native Laravel Gates make that a code change and a deploy; a policy engine makes it a data change.
• Multi-tenant and per-account permission models. Casbin's domain/RBAC-with-domains support maps cleanly to "each organization has its own roles," which is a prerequisite for moving upmarket. This is a gating decision for enterprise tiers, not a nice-to-have.
• Enterprise/security review unblockers. Buyers ask "can we prove who can see what, and can you change it without shipping code?" Policy-as-data gives you a diffable, auditable artifact — useful for SOC 2 evidence and permission reviews.
• Packaging and entitlement gating. Feature flags say on/off; authorization says who, on what, under which conditions. If pricing tiers are becoming entitlement matrices (seats, regions, data residency, export rights), that logic belongs in policy, not scattered if statements.
• Polyglot / multi-service hedge. Casbin has ports across Go, Java, Node, Python, Rust, .NET. If a Go service, a mobile BFF, or a data pipeline ever needs the same permission semantics, one model and one policy store carry over. That's a strategic argument native Laravel Gates cannot make.
• Risk reduction on permission bugs. Centralizing enforcement behind middleware reduces the class of "we forgot a can() check on this endpoint" incidents — a security and support-cost issue, not just a code-quality one.

When to Consider This Package

Adopt when several of these are true:

• You have more than ~5 roles, or a growing role × resource × action matrix, and role definitions are starting to be a recurring support request.
• Non-engineers need to change permissions (support, CS, admins) without a deploy — i.e., you're committing to shipping a permissions admin UI.
• You are multi-tenant and need per-tenant role definitions and isolation.
• You need ABAC-style conditions (owner, department, time window, resource attributes) that would otherwise become dozens of hand-written Gate closures.
• You have, or expect, more than one service or language enforcing the same rules.
• You want policy to be reviewable and revertible as data, not buried in code review.
• Laravel version support and recent releases line up with your stack, and you're willing to run a spike plus an admin UI and decision-logging layer.

Look elsewhere when:

• You have two or three static roles. Laravel's built-in Gates and Policies are idiomatic, zero-dependency, and every Laravel developer already knows them. Casbin here is overhead and a new DSL with no payoff.
• You need Zanzibar-style relationship authorization at scale (nested groups, deep resource graphs, very high query volume). Use OpenFGA or SpiceDB; Casbin covers common RBAC/ABAC but is not a relationship-graph engine.
• Your hot path has tight latency budgets and you can't invest in caching and policy preloading — enforcement plus a DB adapter round-trip is real cost.
• Your team cannot own the model.conf DSL. Debugging "why was this denied?" is meaningfully harder than reading a Policy class; budget for tooling or don't start.
• Procurement or security requires strong third-party validation. 341 stars and minimal public downstream dependency evidence means limited independent production track record. Treat it as a maintained-but-small-footprint dependency: pin versions, read the source, and have a fallback. If that risk posture is unacceptable, buy managed authorization instead.
• You need a turnkey admin UI out of the box — you'll build it, or evaluate Casdoor or a commercial product alongside.

How to Pitch It (Stakeholders)

For executives: Authorization is becoming a sales blocker and a support cost, not a technical detail. Today, changing who can do what is an engineering ticket and a deploy; for a customer-facing product with custom roles and enterprise deals, that's a weeks-long loop. This library moves permission rules out of code and into configuration we control, which is the difference between "we can sell you a custom role model" and "that's on the roadmap for Q3." It's Apache-2.0, so there's no license line item and no per-seat vendor tax, and the policy model is portable if our stack changes. The caveat is maturity: the project is small, so I'd fund a two-sprint spike with a clear fallback rather than a company-wide mandate.

For engineering: It's the Laravel adapter for PHP-Casbin — you define a model (request/policy/effect/matchers) and policies separately, enforce via middleware and a facade, with DB-backed policy storage and caching. It's additive, not a rewrite: keep Gates for the simple, static checks and use Casbin where roles are dynamic, tenant-scoped, or admin-editable. Real costs to plan for: cache invalidation on policy writes, an admin UI and audit log, decision logging so support can answer "why was this denied," and onboarding time on the model DSL. If we're disciplined about caching and keep the model small, the runtime overhead is manageable — but this is a spike-and-measure item, not a drop-in.

Recommended next step: a time-boxed spike on one tenant-scoped surface with a real custom-role requirement, instrumented for enforcement latency and cache hit rate, plus a written comparison against native Gates. Decide on evidence, and only then commit to an admin UI investment.