Security Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication and RBAC. This is the core decision this package informs. nette/security gives you a complete, maintained implementation of three things we would otherwise hand-roll: identity lifecycle (User, SessionStorage, CookieStorage), pluggable authentication (Authenticator / IdentityHandler), and role/resource/permission authorization (Authorizator + ACL). For a greenfield PHP service without an opinionated framework, that is a genuine "buy" — it removes weeks of design and review from the critical path.
• Framework-agnostic security layer as an architectural bet. If our roadmap includes more than one PHP runtime surface (a legacy Nette app, a standalone microservice, a CLI worker that needs permission checks), a framework-neutral component is strategically better than embedding everything in one framework's auth stack. This package is a candidate for that layer; a single-framework solution is not.
• Whether to standardize on Laravel's native auth stack or introduce a second paradigm. For a Laravel codebase this is the real decision, and it is a no by default. Laravel already ships guards, providers, Gate/Policy, middleware, and session drivers, wired through its own container. nette/security is built around Nette's DI SecurityExtension and its own User/IAuthorizator contracts. Adopting it means running two identity models side by side or bypassing Gate entirely — a permanent tax on every engineer who touches authorization. Pick one; document which.
• Scope decision on RBAC granularity. The ACL model here (roles → resources → permissions, with callback-based Permission assertions) covers the admin-panel / multi-role / feature-gating tier well. It does not cover attribute-based or relationship-based authorization (per-record ownership, tenant hierarchies, policy-on-model) without building on top. That tells us what to put in v1 and what to defer.
• Session/identity behavior as an explicit product requirement. Two recent changes are product-level decisions we should make deliberately rather than inherit: User::$persistIdentity (does an identity survive logout for personalization, or hard-null out?) and guest identities via getGuestIdentity() (do anonymous visitors carry their own roles and data?). Both are the kind of thing that shows up as "why does the header still show the user's name after they logged out?" in QA. Having a maintained implementation with a documented answer is worth more than it looks.
• Risk and vendor review gates. Two flags belong on the decision record before any adoption: the license is reported as NOASSERTION, which is not an approval — it needs a five-minute legal confirmation of the actual terms; and the package shows 0 dependents in the data we have, which is a weak-signal ecosystem marker for the Laravel side specifically (it is a well-known Nette component, but that reputation does not transfer).
• Roadmap sequencing for compliance-adjacent work. The v3.2.3/3.2.4 fix — SessionStorage no longer refreshes the sliding expiration once a session has already expired — is the kind of latent bug that fails an audit finding or a pen test. If we are building session handling ourselves, we now own finding and fixing that class of bug. That is a real cost to weigh against the integration cost.

When to Consider This Package

Consider adoption when:

• The codebase is Nette, or framework-neutral PHP, or a mixed estate where a shared auth/ACL layer has to span runtimes. This is where the package is at its best and the integration cost approaches zero.
• You need RBAC with roles, resources, and permission assertions and your requirements stop at roughly that tier — admin panels, internal tools, multi-role SaaS with feature gates.
• Session and identity semantics matter and you want them specified, not invented: sliding expiration that actually expires, cookie storage with sane SameSite handling, an explicit $persistIdentity policy, guest identities with real roles.
• You want maintenance signals you can point at: regular releases, PHP 8.4 and 8.5 support already landed, PHPStan adopted as a mandatory build step, #[\SensitiveParameter] applied to sensitive arguments, and a major-version cadence that keeps BC breaks contained and predictable (v3.2.0's removal of the deprecated IUserStorage is the shape of it — breaking changes arrive in majors, not patches).
• Your team has static analysis in CI. The package now enforces it on itself; a team that does not run PHPStan will not get the safety benefit and will find the type discipline friction rather than value.
• You can absorb a PHP 8.1+ baseline.

Look elsewhere when:

• You are on Laravel and expect this to slot in. It will not. There is no service provider, no middleware, no Laravel session driver, no Gate bridge. The SecurityExtension is a Nette DI extension and does not run in Laravel's container. You would be hand-writing the entire adapter and then maintaining it across every Laravel upgrade. Stay on the native stack — Fortify/Sanctum/Breeze plus Gate and Policies — and spend the effort on policy design instead.
• You need OAuth2, social login, SSO/SAML, or passwordless. Out of scope here. This is core authentication and ACL, not an identity federation layer.
• You need authorization tied to data — per-record ownership, tenant/org hierarchies, policy objects evaluated against models. Laravel Gate/Policy or a dedicated authorization service is the better shape; retrofitting that onto a flat ACL is more work than adopting the right tool.
• You need a non-default session backend — Redis or database-backed sessions with revocation lists and device management. SessionStorage and CookieStorage are the options; anything else is yours to build.
• License ambiguity is a blocker you cannot clear quickly. Treat NOASSERTION as unresolved until legal says otherwise; if procurement is slow, do not start the integration work in parallel.
• You need a large, Laravel-ecosystem community to lean on. 376 stars and no visible Laravel dependents means you will be the one writing the integration guide, not reading it.

Net PM recommendation for a Laravel roadmap: do not adopt as an auth layer. Optionally timebox a one-day spike on the ACL component alone (roles/resources/permissions with assertions) as a candidate permission engine behind Laravel's existing identity — and expect to conclude that Gate and Policies already cover it with less machinery.

How to Pitch It (Stakeholders)

For executives — if you are pitching adoption in a non-Laravel context: "We are choosing to buy our authentication and role-based access control rather than build it. That removes a multi-week block of security-sensitive custom code from the roadmap and replaces it with a component that is actively maintained, already supports current PHP versions, and has recently fixed a real session-expiry defect we would otherwise have shipped ourselves. The cost is adopting someone else's identity model; the benefit is that we do not own the security bugs in it. One item needs your help: the license string is unresolved and needs a legal sign-off before we commit."

For executives — if the question is Laravel: "We evaluated it and are recommending against it. It is a good component, but it is built for a different framework. Making it work in Laravel means writing and permanently maintaining an adapter, and running two identity systems where we currently run one. The security benefit over what we already have is close to zero; the ongoing engineering tax is not. We are keeping Laravel's native auth and investing the same effort in policy design, which is where our actual access-control risk sits."

For engineering: "It solves identity lifecycle and RBAC properly — pluggable authenticators, SessionStorage/CookieStorage, $persistIdentity so logout behavior is a setting rather than an accident, and guest identities that carry real roles instead of a magic string. It is PHPStan-clean with a mandatory static-analysis build, and it tracks new PHP releases fast. The catch is that it is Nette-native: the DI extension does not run in Laravel, and there is no middleware or Gate bridge, so integration is entirely ours to write and own. If we adopt it for a non-Laravel service, great. For the Laravel app, we are not doing it — and the honest reason is that the adapter, not the package, would be the liability."

For security and compliance: "Two things matter here. First, session expiry is handled correctly — an expired session stays expired instead of being silently kept alive, which is the exact behavior that makes audit trails unreliable. Second, permission checks are centralized in one authorizator rather than scattered across middleware and controllers, which makes access reviews tractable. The package also marks sensitive parameters with #[\SensitiveParameter] and enforces static analysis in its own build, which reduces the class of defect we care about. Our caveats: it is a component, not a hardened identity platform — no MFA, no federation, no session revocation across devices. And the license metadata is unresolved, so treat this as not approved for production until legal confirms it."