Filament Social Laravel Package

Product Decisions This Supports

• Build vs. buy for social sign-in. The package supplies the undifferentiated plumbing — OAuth redirects, callbacks, provider credential wiring, account linking, user creation, and Filament-native login/register buttons — so the real decision is whether engineering spends days rebuilding provider boilerplate or reserves that capacity for differentiating work. “Buy” here means adopting a thin MIT dependency, not procuring a supported identity platform; scope the buy decision accordingly, because you are buying a head start, not a vendor relationship.
• Roadmap pull-in for social distribution. If the panel is already Filament, social auth and share actions can move from “next quarter” into the current sprint. v5's per-action shareUrl() / shareTitle() and the component's url / title props turn sharing from a generic button into “share this record” — a demoable increment that may justify shipping sharing now rather than deferring it to a marketing-tool initiative.
• Framework upgrade sequencing — the largest lever. v5 targets Filament 5 / Livewire 4 / Laravel 12–13 / PHP 8.2+, and the Filament 3 line is frozen on a v3 branch. This is no longer a feature-only decision; it couples directly to which Filament major the product standardizes on. Decide the Filament major first, then the package version. Treat the package as an input to the upgrade business case, not a separate roadmap line, and do not let a feature request silently commit the product to a framework migration.
• Admin-surface scope. It supports framing the capability as panel-native — operators connect accounts and trigger share/publish actions inside the admin — rather than standing up a separate social or marketing tool. That is a meaningful scope reduction affecting UX, permissions, and audit-log design, and it keeps social actions inside the surfaces you already govern.
• Use cases it unblocks: agency and multi-client panels where operators manage client social accounts; internal content-ops panels for publishing or triggering social actions; gated community or creator panels where social identity is the login, eliminating a password-reset support queue.
• Security and provisioning policy. The package makes first-login user creation a product decision, not a technical default. Auto-creating a panel user from any Google account is a security incident queued up. The PM must pick explicitly between auto-create, existing-email-only, domain allowlist, or an approval step — and decide deliberately whether email-based account linking is permitted, since auto-linking a password user to an unverified provider email is an account-takeover vector. Write the policy down before the feature ships; engineering cannot infer it from the package.
• Multi-panel and tenancy posture. The plugin is panel-scoped, so the PM can decide which providers appear on admin vs. app vs. tenant panels rather than shipping one global setting. Tenant callbacks resolve before tenancy initializes, so the post-login redirect and tenant context must be validated before tenancy support is promised to customers or sales.
• Ecosystem and risk posture. Adoption is a bet on the tomatophp Filament plugin family and its conventions. At roughly 14 stars, zero dependents, and a single-maintainer profile, the decision is: adopt directly, adopt behind an internal adapter so it stays replaceable, or fork and own it. Default to the adapter — it keeps the feature reversible without slowing delivery, and reversal is cheap insurance against maintainer abandonment.
• Support-cost expectations. v5 changed both the data model and the supported stack. Plan for a read-the-changelog-before-every-bump discipline plus a per-environment OAuth click-through smoke test; that recurring cost is the price of the dependency and belongs in the estimate, not in the surprise column later.

When to Consider This Package

Consider it when:

• The product already runs a Filament panel on a supported stack (Filament 5 / Livewire 4 / Laravel 12–13 / PHP 8.2+) and the team wants social login on the panel login and registration pages without writing OAuth handling.
• Faster onboarding is a measurable goal. Reducing signup friction for a gated community, creator platform, or partner portal is a retention and activation argument, not just a convenience.
• Social actions belong inside the admin. Operators publishing or sharing per-record content from the panel is the intended shape; if sharing is a public-facing marketing widget, this is the wrong tool.
• You can absorb single-maintainer risk. The team has the discipline to pin ^5.0, read changelogs, keep a callback test green, and wrap the package behind a thin internal adapter.
• A first-login policy already exists or can be decided quickly. Governance (allowlists, approval, role assignment) is a prerequisite, not a follow-up ticket.
• You are already on the matching Filament major. The version lines are locked together; adopting this should not be the forcing function for a framework migration unless one is already funded.

Look elsewhere when:

• The panel is not Filament, or is on Filament 3 with a near-term plan to stay there — the v3 branch is a maintenance line, and you would be building on a frozen target.
• You need enterprise identity — SSO/SAML, SCIM provisioning, MFA orchestration, audit and compliance guarantees, or a support contract. That is an identity platform decision, not a plugin decision.
• Security review cannot tolerate auto-provisioning ambiguity. If the org cannot commit to an allowlist or approval step, defer the feature rather than shipping permissive defaults.
• Tenancy is a launch requirement and the callback/tenancy ordering cannot be validated in time.
• You need provider breadth beyond Socialite's core set or non-OAuth social integrations.
• Uptime and lifecycle guarantees are contractual. A single-maintainer MIT package with zero dependents cannot underwrite an SLA — though it is fine behind an adapter you control.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version. This is a small, free, MIT-licensed addition to the admin panel we already run. It gives our operators “Log in with Google” (and similar providers) on the panel sign-in page and lets them share specific records straight from the admin, instead of us building OAuth plumbing from scratch. The business case is time-to-market, not license cost: it converts a multi-day integration into a configuration task and lets us demo social onboarding this sprint. The honest caveats are that it is maintained by one developer with a small user base, and its newest major version requires our Filament 5 stack. We mitigate both by pinning the version, wrapping it behind a thin internal interface so we can swap to plain Laravel Socialite in an afternoon, and keeping an automated sign-in test that trips if an upgrade breaks us. The main decision we need from leadership is policy, not technology: who is allowed to become a panel user via social login. Auto-creating accounts from any Google address would be a security incident waiting to happen, so we recommend domain allowlisting or an approval step from day one.

For engineering — the summary. It wraps Laravel Socialite into Filament's auth pages and registers as a panel plugin; it handles the redirect/callback cycle, resolves or creates a user, and stores provider profile data in a social_auth_users table — the v5 data model, replacing the old users.data writes, so any dashboard or script reading the old location must be updated in the same change. Version lines are locked: Filament 5 → ^5.0, Filament 3 → ^3.0, and mixing fails at install or at runtime on the auth page. The known risks are redirect-URI drift (the callback must include the panel path), guard/panel mismatch producing login loops, config-cache staleness that looks like a package bug, and returning-user regressions — which is why the second sign-in is a mandatory test, not an afterthought. Keep an explicit returning-user test and a Pest Socialite::fake suite, keep a staging click-through because OAuth cannot be validated from localhost without a tunnel, and keep the callback logic behind a small adapter so removing the package is a bounded task. Filament's own actions cover generic sharing; prefer them where they fit and reach for this package's share components when you need record-specific url / title values rendered inside panel views.