Scoped Auth Laravel Package

Product Decisions This Supports

• Multi-tenant / B2B SaaS roadmap: Informs whether "organizations," "workspaces," or "brands" get truly isolated authentication. Scoped auth lets one user identity hold separate sessions per scope, so signing into Tenant A does not silently authenticate you into Tenant B — a security and trust requirement for any B2B motion.
• Build vs. buy on auth plumbing: The alternative is a custom guard + session-key rewrite + Fortify/Breeze patching — roughly a multi-sprint effort with ongoing security review. This package is a thin, replaceable layer over Laravel's native guard, so it converts a bespoke build into a small dependency.
• Feature unlock: Tenant switcher UX, agency/client portals, white-label deployments, marketplace seller vs. buyer contexts, and scoped admin impersonation all become low-cost features rather than architecture changes.
• Upgrade planning: The v2.1.1 signals (Laravel 14 support, PHP 8.5 CI) are direct inputs to "can we stay on supported Laravel/PHP versions without forking auth code?" — relevant to the platform-upgrade line on the roadmap.
• Risk register: Single-maintainer project with AI-assisted PRs ([Claude]) — worth tracking as a supply-chain/maintenance dependency rather than a load-bearing framework choice.

When to Consider This Package

Adopt when:

• You are (or are about to become) multi-tenant, and the same human user legitimately belongs to more than one tenant/scope.
• You need session-level isolation per scope, not just authorization checks — i.e., cross-tenant session bleed would be a security incident.
• You use Laravel session-based auth with Fortify, Breeze, or a custom login flow you want to keep.
• You are on a supported Laravel/PHP combination; v2.1.1 explicitly covers PHP 8.5 and Laravel 14, so it will not block a platform upgrade.
• You want a small, swappable dependency rather than owning auth internals.

Look elsewhere / skip when:

• Single-tenant product, or users are globally unique with no per-tenant membership — the abstraction buys you nothing.
• Purely API/token-based auth (Sanctum, Passport, OAuth) where there is no server-side session to scope.
• You need roles/permissions/ABAC — that is spatie/laravel-permission + policies; this package answers "who is logged in for this scope," not "what may they do."
• You require vendor SLAs, multiple maintainers, or a security review process with named ownership. This is a one-maintainer package; budget for the ability to fork (it is small enough to).
• You are locked to an older Laravel major without an upgrade path.

Release-specific read on v2.1.1: patch release, no breaking changes, no deprecations. Changes are CI matrix expansion (PHP 8.5), a Fortify documentation fix, and Laravel 14 support. Nothing alters runtime behavior on existing versions — safe to take on a routine dependency bump. Notable as evidence of health: the maintainer tracks new Laravel/PHP releases quickly, which de-risks your own upgrade calendar. Notable as evidence of concentration: all three PRs are AI-assisted and merged by the same person.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-cost component that lets us support customers who belong to multiple organizations without their logins bleeding across accounts. The alternative is roughly a quarter of engineering work on custom authentication code plus permanent security-ownership overhead. The package is actively maintained, already supports our next Laravel and PHP upgrades, and this release is a compatibility-only patch with no breaking changes — so it is a cheap option on a capability we will likely need, not a bet.

For engineering (the honest version): It extends Laravel's native guard rather than replacing it, so the blast radius is small and reversible — expect a contained integration behind our existing auth layer, with a documented fallback of a custom guard if we ever need to drop it. v2.1.1 is a no-risk bump: PHP 8.5 in CI, a Fortify docs correction, and Laravel 14 support. Caveats to accept explicitly: single maintainer, AI-assisted contributions, and a narrow scope — it does not solve authorization, so pair it with policies and keep RBAC decisions in our own code. Ask: pin the minor version, add it to the dependency-review list, and treat any future major as a planned migration.