Auth Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication. Auth is non-differentiating but high-blast-radius. This package is a candidate to borrow rather than build, contingent on the maintenance question below. It shifts the build estimate from "design a login system" to "integrate and security-review a login system."
• Time-to-first-user / onboarding funnel. Registration, social sign-in, magic link, and password reset all land on redirect()->intended(Home::url(...)) with a reason (login, registered, verified). That reason is the hook for routing new accounts into onboarding, activation, or a paywall — a decision you otherwise have to wire yourself.
• Signup friction experiments. Magic link (passwordless) is a first-class flow, disabled by default with a configurable expiry. This gives you a real A/B lever — password vs. magic link vs. social — without new engineering, and it's the cheapest way to test whether password creation is costing you conversions.
• Social provider scope. Google and GitHub only. That is a defensible default for developer and SMB tooling. If you're consumer or mobile, this decides an Apple Sign-In work item (App Store requirement) onto the roadmap before launch, not after.
• Closed beta / invite-only launch. registration_enabled, magic_link_enabled, and enabled_socialite_providers are runtime settings, and disabled routes 404 rather than silently failing. You can gate signup per-environment or per-cohort without a deploy.
• Modal vs. full-page auth as a conversion decision. modal_enabled swaps navbar links to modal entry points while keeping canonical pages. This makes the "does modal login convert better than a dedicated page?" question a settings toggle, not a sprint.
• Support tooling and cost-to-serve. Admin impersonation with a capped recent-history list (impersonation.recent_history, max 4 IDs, 3 shown) is a real support-cost reduction — reproducing a user's bug in their own session instead of over a screen share. It also creates a privacy/audit obligation you should consciously accept.
• Trust and security signalling as features. New-sign-in notifications (gated on login_notification_enabled) and connected-account management in a separate Security panel are user-visible trust features, not just plumbing. They belong in release notes and pricing-page security copy.
• Identity vs. credentials as an information architecture. The Profile/Security split (name/email/avatar vs. password/connected accounts) is a UX stance worth adopting even if you don't adopt the code — it matches how users reason about "my account" vs. "how I get in."
• Email verification as a product gate. You must decide whether verification is enforced or merely recorded. Today the timestamp is tracked but User does not implement MustVerifyEmail, so the verified middleware is a pass-through. Any roadmap item that assumes verified-email gating (marketplace trust, password recovery guarantees, outbound email reputation) is currently unbacked and needs an explicit decision.
• Enterprise/SSO deferral. No SAML, OIDC-SSO, MFA/TOTP, or passkeys. That's fine for self-serve SMB and a hard blocker for a mid-market motion — treat SSO as a segment-gating decision, not a backlog item.

When to Consider This Package

Consider it when:

• You are building on the Saucebase stack (Laravel + Inertia + Vue/React, Filament admin, its settings-modal shell). The module assumes Home::url(), core's settings modal, Filament, and tenancy's impersonation handoff — it is a module, not a standalone package.
• You need the standard self-serve auth set and nothing exotic: password login, registration, social (Google/GitHub), magic link, reset, verification, profile/security settings.
• You are a small team without a dedicated security engineer and would otherwise hand-roll this. The baseline quality is genuinely above typical hand-rolled auth: magic-link tokens stored only as SHA-256 hashes and consumed in a single atomic UPDATE (one-time use even under concurrent clicks), email_verified_at deliberately excluded from $fillable, logout restricted to POST with a documented reason, rate limiting at 5 attempts per email|ip with Lockout events, social-account linking that blocks takeover of an ID owned by another user, and a guard against disconnecting your only login method.
• You plan to use Filament for internal admin — you get a Users resource, role handling, and impersonation for free.
• You are validating a product and speed dominates. Integrating this is days; a careful from-scratch build with the same security properties is weeks.

Look elsewhere, or budget remediation, when:

• Adoption risk is unacceptable. 2 stars, 0 dependents, no community. Treat this as vendored internal code you now own, not a dependency with an ecosystem behind it. No third-party bug reports, no Stack Overflow surface, no security advisories list. Fork-and-maintain should be the assumed operating model, and that needs an owner's name.
• You are not on the Saucebase core stack. The core coupling is deep enough that extracting it costs more than adopting an established alternative.
• You need MFA/TOTP, passkeys/WebAuthn, or enterprise SSO. None are present.
• You need API/token auth for mobile or third-party clients — this is session/browser auth; no Sanctum or OAuth2-server story here.
• You require enforced email verification today. It is tracked but not enforced, and the import is commented out. Don't ship a roadmap that depends on it without scheduling the work.
• You require session invalidation on password change. Not implemented; the docs flag it as blocked on AuthenticateSession in the web group — an app-wide change awaiting a regression pass (sc-714). This is a known security gap, not a bug.
• You need a supported vendor relationship, SLA, or CVE response commitment.
• Provider coverage must extend beyond Google/GitHub (Apple, Microsoft, Facebook, generic OIDC) — each is net-new work here.

How to Pitch It (Stakeholders)

For executives: Authentication is the highest-consequence, lowest-differentiation code we will write. Getting it wrong is a breach headline; getting it right wins us nothing competitively. This module gives us a hardened baseline — password and social login, passwordless magic links, reset and verification, self-service account settings, and an admin impersonation tool that will measurably cut support time — for days of integration instead of weeks of senior engineering. It also hands us two levers we'd otherwise build: magic-link signup as a conversion experiment, and a modal-vs-page login toggle as a pure settings change. The honest caveat: nobody else uses this. Two stars, zero dependents. We would be adopting it as vendored code we own, and I need a named maintainer before we commit. Two functional gaps matter and are already documented: email verification is recorded but not enforced, and changing a password does not end other active sessions. Neither blocks a launch, both need a dated owner, and the second is a visible "we take security seriously" item for any enterprise buyer.

For engineering: This is a well-shaped module, not a demo. Token handling is correct — magic-link tokens are stored only as hashes and consumed in one atomic statement, so a database compromise yields no forgeable links and concurrent clicks can't replay. email_verified_at is out of $fillable, so no request payload can self-verify. Social linking refuses to attach an identity already owned by another user, and disconnection is refused when it's the only login method. Impersonation asks can('impersonate', $target) in all three entry points, admins are unpoliced-out of reach, and nobody can delete their own account. Two things to budget for before you commit: (1) enable MustVerifyEmail and actually enforce verified — it's currently a pass-through with the import commented out; (2) close sc-714 so a password change invalidates other sessions, which requires AuthenticateSession in the web group plus a regression pass. Also accept the coupling: this depends on the core settings modal, Home::url(), Filament, and tenancy's impersonation handoff. If we're not on that stack, the extraction cost exceeds the value. Review skills/saucebase-auth-development/SKILL.md before touching anything — it documents the non-obvious invariants (why logout is POST-only, why login opens in a modal only when the header is present, why password-change sessions are still open).