Weave Code
Laravel Socialiter Laravel Package
genealabs/laravel-socialiter
Socialiter adds social login to your Laravel app with minimal setup. Connect OAuth providers, link social accounts, and let users sign in with one click via Facebook, Google, GitHub, and more—all through a simple, configurable API that integrates cleanly with Laravel Socialite.
Automatically manage user persistence and resolution for any Laravel Socialite provider.
Frequently asked questions about Laravel Socialiter
- How do I install genealabs/laravel-socialiter in a Laravel app?
- Install it with Composer using composer require genealabs/laravel-socialiter, then publish the package's config file and migrations through the standard vendor:publish workflow. Next, add your OAuth provider credentials (client ID, secret, redirect URI) to your config and expose the package's callback route so Socialite can hand the response back. Finally, decide whether you need a custom user-creation callback or whether the default resolution behavior is enough. The package is additive, so nothing in your existing User model has to be rewritten.
- Which Laravel and PHP versions does laravel-socialiter support?
- The v13 release is a platform-alignment release targeting Laravel 13 and PHP 8.5, so check the exact version constraints in composer.json for the tag you intend to install rather than assuming. The release notes for v13 describe additions such as the custom user-creation callback, not removals, but that does not by itself prove Laravel 11/12 or PHP 8.2–8.4 were dropped. Confirm the supported matrix in composer.json before committing, because it determines whether adopting v13 is gated on a runtime upgrade your team has not otherwise planned.
- Do I have to change my User model to use Socialiter?
- No. Socialiter is designed so your application's User model remains authoritative, and the package only owns the social identity and token persistence concern you would otherwise hand-roll. That separation means you can adopt it without a domain-model rewrite and remove it later without unpicking your user table. Keep identity and token lookups behind the package rather than querying those tables directly from your app code, so the boundary stays clean.
- How do I add Google, GitHub, or Facebook login with Socialiter?
- Socialiter sits on top of laravel/socialite, so you configure provider credentials the same way you would for Socialite and register the provider through the package's configurable API. Each provider entry maps to a redirect and callback flow that the package handles, which means social login becomes a configuration task rather than a controller-per-provider task. Supported providers are any that Socialite supports, including Google, GitHub, and Facebook.
- How do I customize what happens when a new user signs in with a social account?
- Version 13 adds a custom user-creation callback that inverts control into your application code, so you decide how a first-time social sign-in maps to a User record instead of the package making that decision. That is the right seam architecturally, but treat it as a contract: confirm the callback signature, its return semantics, and how exceptions propagate before relying on it. Check whether it is covered by tests in the release you install. Adopt the callback as a separate, later change so any regression stays isolatable from the upgrade itself.
- Can Socialiter coexist with existing email and password login in my app?
- Yes, and v13 specifically fixes a password-overwrite bug so that an existing email/password user signing in socially for the first time no longer has their password clobbered. That is what makes safe coexistence of both login methods possible. The catch is behavioral: any test, seeder, QA script, or downstream job that asserted post-login password state will now see different results. Run an explicit login-path regression pass for both password and social flows after upgrading.
- What should I check before upgrading to Socialiter v13?
- The highest-risk change is the modernized database migrations, because Laravel records migrations by filename: if stubs were renamed, consolidated, or columns retyped, existing installs will not re-run them and will silently keep the old physical schema while fresh installs get the new one. That split-brain state typically surfaces months later when a query assumes an index or column that only new environments have. Diff the published migration stubs between your installed version and v13 and, if anything changed shape, write a targeted remediation migration instead of republishing blindly. Also confirm whether the schema still indexes the identity lookup column used on every social login.
- How do I test social login flows without hitting a real OAuth provider?
- Because Socialiter delegates to laravel/socialite, you can mock or fake the Socialite user response in your test suite and assert that the package resolves or creates the right user, then redirects correctly. Cover three paths explicitly: a brand-new social user, an existing social identity, and an existing email/password user signing in socially for the first time, since that last path is where the v13 password fix changes behavior. Add an assertion that distinguishes a null password from a set one so the regression stays caught.
- Does Socialiter store OAuth access tokens, and are expired tokens pruned?
- The package owns social identity and token persistence, so provider tokens are stored on its own tables rather than in your User model. Whether expired or revoked tokens are pruned on a schedule is something to verify in the version you install, along with whether the modernized schema still indexes the identity lookup column. If pruning is not built in, add a scheduled job to avoid unbounded table growth and stale-token exposure.
- Is Socialiter a good alternative to hand-rolling Socialite callbacks?
- If your app is conventional Laravel with a standard Eloquent user model and standard OAuth providers, Socialiter replaces the redirect-callback-user-resolution code you would otherwise maintain yourself, at low integration cost. It is a poor fit if identity is already federated to Auth0, Cognito, or Keycloak, because you would create a second source of truth for credentials, which is a compliance problem rather than mere redundancy. It is also not a path to SAML or OIDC federation. Evaluate it as commodity infrastructure you can sponsor and later remove, not as an identity platform.
Weaver
How can I help you explore Laravel packages today?