- How do I install mad-web/laravel-social-auth in a Laravel app?
- Install it with Composer, publish its configuration so you get config/social.php, then add provider credentials and redirect/callback routes. The package is a thin wrapper over laravel/socialite, so you still resolve or create the user in your own controller. Because the package appears unmaintained, verify its Composer constraints against your Laravel and Socialite versions before adopting it.
- What does mad-web/laravel-social-auth actually do compared with Laravel Socialite?
- It adds a config-driven manager and facade that resolves OAuth providers by driver name from config/social.php, so you do not wire a controller and service provider for every provider. It does not replace Socialite; it is an adapter over Socialite drivers. It also does not own users, tokens, sessions, or account linking, so those remain application responsibilities.
- Which providers can I use for social login with this Laravel package?
- It supports providers available through laravel/socialite, such as Google, Facebook, and GitHub, plus any other Socialite driver you configure. The exact list depends on your Socialite version and any community drivers you add. Providers needing OAuth 1.0, custom scopes, or PKCE should be checked against Socialite before relying on the wrapper.
- Is mad-web/laravel-social-auth maintained and safe for production authentication?
- The assessment flags abandonment as high risk: zero stars, zero dependents, and no visible release cadence in the snapshot. An unmaintained dependency on the login path has no CVE disclosure channel, no upstream patches, and no compatibility guarantees. For production auth, prefer laravel/socialite directly or fork and own the small wrapper.
- Which Laravel and PHP versions does this social auth package support?
- The snapshot does not provide a reliable support matrix, so you must check the package's composer.json constraints against your target Laravel and PHP versions. The bigger risk is Socialite version drift, because the wrapper depends on Socialite driver-resolution internals that have changed across majors. Test against the exact Laravel and Socialite versions you plan to support for the next 24 months.
- How do I configure providers like Google and GitHub in config/social.php?
- You declare each provider in config/social.php with its driver name and credentials, then resolve it by that name at runtime. Client secrets should be injected through environment variables and rotated like any other OAuth secret. Confirm that the wrapper still delegates state and PKCE validation to Socialite and does not bypass it.
- Can this package handle account linking, token refresh, or post-login provider API calls?
- No. It is only an adapter for the login redirect and callback flow; it does not own users, tokens, sessions, or account linking. Token storage, refresh, and on-behalf-of API calls after login are your application's responsibility. If you need provider-agnostic identity modeling or an identity broker, this package is not the right layer.
- What are the security risks of linking social accounts by email in Laravel?
- Linking accounts by email is an account takeover vector if your resolver trusts an unverified provider email. GitHub private emails and Apple private relay addresses are common examples where the email may not prove ownership of your local account. Require verified email claims or an explicit linking flow before merging social identities.
- How should I test social authentication with this package?
- Test your own callback controller and user-resolution policy, because that is where the application logic lives. Mock or fake the Socialite user response and cover new-user creation, existing-user login, linking, unverified email, and provider error cases. Also test the wrapper boundary so a future swap to native Socialite or an in-house manager stays mechanical.
- What is a better alternative to mad-web/laravel-social-auth for Laravel social login?
- Use laravel/socialite directly and add a small in-house SocialAuthManager service plus one controller for /{provider}/redirect and /{provider}/callback. That is roughly 100 to 150 lines, fully testable, and keeps the config-driven ergonomics without the maintenance surface. If the package is already installed, wrap it behind your own SocialAuthService interface so the facade never leaks into domain code.