Laravel Socialiter Laravel Package

Product Decisions This Supports

• Social-login roadmap sequencing. The package collapses "Sign in with Google/GitHub/Apple/etc." into configuration rather than an OAuth lifecycle build. The product decision is which providers, in what order, and when — not how to handle callbacks, persist identities, or associate accounts. Prioritize providers by measured demand and observed drop-off on the email/password form, and treat each additional provider as a config change rather than a project.
• Build vs. buy (buy, but a bounded bet). Social authentication is infrastructure, not differentiation. MIT license, 134 stars, zero listed dependents, one maintainer: the correct framing is "adopt cheaply, keep the integration thin, stay fork-ready," not "procure a supported identity platform." Engineering capacity is better spent on onboarding, provisioning, and account linking — the parts users actually experience.
• Onboarding and access policy at first social login. The v13 custom user-creation callback (PR #19) is the strategically meaningful addition. It is where you encode invite-only access, waitlists, workspace/tenant assignment, default roles, CRM enrichment, or terms acceptance at the moment an OAuth user is created. This is a product lever with a deadline: decide the policy before rollout, because retrofitting it onto already-created users is a data migration, not a config change.
• Account-linking and credential-safety policy. The password-overwrite fix (PR #18) means an existing email/password user who later signs in with Google keeps their password. That makes coexistence of both login methods safe and makes a "link your social account" surface viable. It also invalidates any prior QA expectation or product assumption that a first social login resets the password.
• Platform-upgrade planning. v13 bundles Laravel 13 and PHP 8.5 alignment with a migration modernization (PR #17) and the behavioral change above. From a roadmap standpoint this is maintenance — but it must be scheduled as its own workstream with its own risk budget, not ridden along on a feature release.
• Segment fit. Consumer apps with friction-sensitive signup, B2B and external-user portals, marketplaces and communities, and internal tools where standard OAuth providers suffice. Those are the segments where the package's scope matches the need.
• What this explicitly does not unlock. Enterprise SSO, SAML/OIDC federation, SCIM provisioning, fine-grained RBAC/ABAC, multi-tenant identity, or audited/SLA-backed identity. If any of those is on the 12-month horizon, adopting this now accrues migration debt rather than saving time — make that call deliberately rather than discovering it mid-enterprise-deal.

When to Consider This Package

Consider it when:

• You run a Laravel app with a conventional Eloquent user model and need standard Socialite provider login with persisted users and linked accounts.
• You would otherwise hand-roll the OAuth callback, user creation, and account-association logic — and you accept community-level support (GitHub issues, no SLA, no visible security disclosure policy).
• You need a provisioning seam at first login: invite gating, roles, waitlists, CRM sync. The v13 callback is exactly that seam.
• You can keep the integration thin: published config and migrations only, no direct queries against the package's identity/token tables from application code, no forks of its internals.
• You can name an owner for "re-validate at each Laravel major." That recurring cost is the true total cost of ownership here.

Gate it heavily when:

• You are moving to v13. It is a major that combines platform alignment, a migration modernization, and a security-relevant behavior change. The migration item is the top risk: Laravel records migrations by filename, so renamed, consolidated, or retyped migrations will not re-run on existing installs — fresh databases get the new schema, upgraded ones silently keep the old one. Require a staging migration rehearsal, a diff of v13 stubs against both v12 stubs and your own database/migrations directory, and a hand-verified schema comparison against a fresh v13 install before cutover.
• Your host app is not already on the target platform. If the Laravel 13 / PHP 8.5 upgrade isn't on the roadmap, defer the release — there's no product reason to absorb migration risk for platform alignment you aren't using.
• You have code, analytics, or QA that touches the social-accounts table or asserts post-login password state. Those are directly coupled to PR #17 and PR #18.

Look elsewhere when:

• You need enterprise SSO/SAML/OIDC/SCIM, identity federation, multi-tenant identity, fine-grained authorization, regulatory audit guarantees, or commercial support with an SLA.
• Identity is already federated to an external IdP (Auth0, Cognito, Keycloak). Socialiter would duplicate paid capability, and its token table becomes a second source of truth for credentials — a compliance problem, not just redundancy.
• You are not on Laravel, or you need provider/customization behavior beyond its scope.
• A single-maintainer bus factor is disqualifying for your risk posture. There is no co-maintainer, foundation, or commercial tier. Mitigate by bounding blast radius — thin integration, fork-ready posture — not by assuming the risk away.

Open questions to close before committing:

• What is the actual supported version matrix in v13 — does it drop Laravel 11/12 or PHP 8.2–8.4? Check composer.json in the tag; the release notes state additions, not removals.
• Were migrations added only, or renamed/altered? Renamed or altered means a targeted remediation migration, not republishing stubs over applied files.
• What is the exact contract for the custom user-creation callback — signature, return semantics, exception behavior, test coverage? An undocumented extension point becomes a liability at the next major.
• Is there a regression test for the password-overwrite fix, and does it distinguish null from a set password?
• Are expired/revoked tokens pruned? If not, plan a cleanup job and review indexes on the identity lookup column — a schema-modernizing migration is precisely where an index disappears unnoticed until p95 login latency degrades.

How to Pitch It (Stakeholders)

Executives. This lets us ship social sign-in faster and cheaper than building OAuth user management in-house. It's commodity infrastructure, MIT-licensed, no procurement cycle, and it keeps our User model authoritative so it can be removed without a data-model rewrite. Version 13 aligns us with Laravel 13 and PHP 8.5, adds a customizable user-creation hook so onboarding policy lives in our code, and fixes a password-overwrite issue that protects existing users on their first social login. Two caveats stated plainly: it's a single-maintainer community package with no support SLA, and v13 bundles a database migration change plus a behavioral change to the login path. Recommendation: adopt or upgrade gated on a staging migration rehearsal and a login-path regression pass, with the previous version pinned in a rollback branch for one release cycle. Cost is bounded — roughly a day of mid-level Laravel developer time, plus a recurring "re-validate at each Laravel major" line item.

Engineering. v13 is a platform-alignment major, not a patch. Sequence it deliberately: pin ^12.0 in production today so a floating constraint can't pull v13 unreviewed; upgrade the host app's PHP and Laravel versions independently first; then diff the v13 migration stubs against v12 and against our own migrations directory — that diff is the single most important artifact in this upgrade. If migrations were only added, republish normally; if renamed or altered, write a targeted remediation migration and verify the resulting schema against a fresh v13 install. Exercise both paths in staging: brand-new social user creation (including the callback) and an existing user's first social login (the password fix). Keep the integration thin — don't fork migrations, don't query the package's identity/token tables directly, don't depend on undocumented internals. Confirm the composer.json constraints in the tag, the resolved laravel/socialite major, and DB-engine behavior for the modernized column types (SQLite-passes/MySQL-fails is a known failure shape). Adopt the user-creation callback as a separate, later change so regressions stay isolatable during the risky step.

Product. The user-creation callback is the lever: use it to encode onboarding and account-linking policy — invite-only access, waitlists, role assignment, workspace/tenant defaults, terms acceptance — before rollout, because retrofitting policy onto already-created users is a migration. Decide the account-linking posture explicitly now that social login no longer clobbers an existing password; coexisting email/password and social login is safe, which makes a "link your account" surface viable. Prioritize providers by measured demand and form abandonment. Instrument signup conversion, login-related support-ticket volume, and account-takeover signals before and after rollout, and define rollback behavior for a callback that throws after the user row is written — the new extension point increases exposure to orphaned users. Provider-side API changes will break a subset of logins without warning, so treat a per-provider synthetic login smoke test as a reliability requirement, not a nice-to-have.