Insideauth Laravel Package

Product Decisions This Supports

• Authentication architecture standardization: v0.2.13 lets getAuthenticator() be called without a name and fall back to the default auth guard, which signals the package is maturing toward a conventional "default + named authenticators" model. This supports a decision to standardize multi-guard authentication on this package rather than hand-rolling guard resolution per feature.
• Build vs. buy for auth plumbing: the package now exposes the full list of authentication classes it manages, which can be fed directly into Livewire's addPersistentMiddleware. That is a concrete integration seam — teams can buy this instead of building custom Livewire/auth middleware wiring, which is otherwise easy to get subtly wrong (auth context lost between Livewire requests).
• Feature enablement for multi-portal / multi-persona products: admin + customer + partner logins, tenant-scoped guards, or separate API/session authenticators become cheaper to support when authenticator selection is centralized and defaultable.
• Livewire-heavy roadmap bets: if the roadmap leans on Livewire for dashboards or authenticated SPA-like flows, this release directly de-risks "auth state survives component requests" — a recurring source of bugs and support tickets.
• Use cases: multi-guard Laravel apps, Livewire apps with authenticated components, internal tools with distinct user populations, and incremental migration from bespoke auth middleware.
• Roadmap signal: the API is still adding convenience parameters at v0.2.x, so plan for adoption behind a thin internal abstraction rather than spreading calls across the codebase.

When to Consider This Package

Consider adoption when:

• The application genuinely has more than one authenticator/guard (e.g., web, admin, api, tenant-specific guards) and guard selection logic is currently duplicated or scattered.
• You use Livewire and need authenticated middleware to persist across component requests; the new authenticator-list parameter is purpose-built for passing into addPersistentMiddleware.
• You want to reduce boilerplate: the optional name parameter on getAuthenticator() removes repetitive explicit guard naming for the common default case.
• You are comfortable with a pre-1.0 dependency (v0.2.x) and can absorb minor API churn; pin versions and wrap usage in your own service/helper.
• The team values a small, focused package over pulling in a larger auth/ACL framework.

Look elsewhere when:

• The app has a single guard and no Livewire auth-middleware needs — native Laravel auth is sufficient and this adds a dependency for no gain.
• You require a stable, semantic-versioned public API (1.0+) or vendor support/SLAs; v0.2.x is still evolving.
• You need full identity features (SSO, MFA, social login, authorization policies) — this package addresses authenticator/guard management, not a complete auth platform.
• Your organization has strict dependency-review or security-review gates that a young, low-adoption package may not clear.
• The auth requirement is better served by first-party Laravel/Sanctum/Fortify features plus a small amount of custom middleware.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost Laravel dependency that removes custom authentication plumbing, particularly for apps with multiple user types and Livewire-based interfaces. The latest release (v0.2.13) makes the common case simpler and closes a real integration gap with Livewire, reducing a class of auth bugs that otherwise surfaces late in QA or in production. Risk is contained: it is pre-1.0, so we recommend a time-boxed pilot behind an internal wrapper, pinned versions, and a fallback to native Laravel auth if the package stalls.

For engineering: v0.2.13 adds two useful capabilities — getAuthenticator() now defaults to the auth guard when no name is supplied, cutting boilerplate, and the package exposes the list of authentication classes it manages, which can be passed to Livewire's addPersistentMiddleware so guard context survives component requests. Proposed approach: adopt behind a thin internal adapter, pin the minor version, add a smoke test covering default-guard resolution and Livewire persistent middleware, and track upstream toward 1.0 before broadening usage. Build-vs-buy verdict: buy for multi-guard + Livewire scenarios; defer for single-guard apps.