- What does smorken/social-auth actually do?
- It is a Laravel helper package that adds social authentication so users can log in through third-party OAuth providers. Functionally it is a thin wrapper around Laravel's first-party Socialite, shipping routes, a controller, provider configuration, a migration for storing provider identity, and a policy for creating or linking users. It is not a full OAuth implementation of its own, and the capability it provides is roughly what most teams write themselves in a day or two.
- How do I install smorken/social-auth if it is not on Packagist?
- Because the package is hosted only on Bitbucket and has no Packagist presence, Composer cannot resolve it by name. You need to add a repositories entry of type vcs pointing at https://bitbucket.org/scott_morken/social-auth.git, and every developer machine and CI runner needs Bitbucket credentials to clone it. That means you also lose the usual version constraint, security advisory, and artifact reproducibility pipeline, so pin to a specific commit SHA and commit your lockfile.
- Is smorken/social-auth a wrapper around Laravel Socialite or a reimplementation of OAuth?
- The evaluation describes it as a thin Laravel wrapper around first-party Socialite, handling routes, a controller, provider config, the provider identity migration, and the user create/link policy. That is the tolerable shape, since the actual OAuth handshake, state handling, and provider drivers stay with Socialite itself. Before adopting, confirm by reading the source that it does not reimplement the handshake; a reimplementation should be treated as a reject.
- How does smorken/social-auth link a social account to an existing user?
- It ships an opinionated create/link policy plus a migration for provider identity, but the exact matching rule needs to be verified in the source. The critical question is whether it links on provider ID only, on an explicit user action, or on an unverified provider email address. Auto-linking on an unverified email is a severe account takeover risk, so gate adoption on a security review of that linking logic.
- Which Laravel and PHP versions does smorken/social-auth support?
- The package metadata does not declare this clearly, so check the composer.json constraints on PHP, illuminate/support, and laravel/socialite before committing. Narrow illuminate or Socialite constraints can block a framework upgrade, so verify the package against your next-major Laravel target before the spike. If the constraints are tight or outdated, plan to fork the code rather than force a resolution override.
- Is smorken/social-auth safe to use in production?
- There is no adoption evidence to lean on: zero stars, zero dependents, no Packagist listing, Bitbucket-only hosting, and a composite score of zero. That does not prove the code is bad, but it means nobody else has reviewed it, and you would be inserting an independently versioned dependency into a security-critical login path. Treat it as a reference implementation or an estimation artifact, not a candidate platform dependency, unless a security review clears it.
- Where does smorken/social-auth store OAuth access and refresh tokens?
- The package includes a migration for provider identity, but the metadata does not state whether access and refresh tokens are persisted or how they are protected. Token persistence is one of the few genuinely opinionated things a package like this could save you from writing, so confirm where tokens land and whether they are encrypted at rest. If tokens are stored in plaintext columns, that is a finding for your security review before any exposure.
- What should I use instead of smorken/social-auth?
- The recommended path is implementing the same surface directly on laravel/socialite, which ships with the framework and is maintained on Laravel's release cadence. A controller, a callback route, a provider and provider_id migration, and an explicit linking policy are roughly one to three engineer-days of work. You then own the security semantics and the upgrade path, and you avoid a second unvetted dependency in your authentication flow.
- Does smorken/social-auth have tests, and how do I catch callback breakage after upgrades?
- The available signals do not confirm a test suite, particularly one covering callback failure paths. Callback breakage after a Laravel or Socialite upgrade is the highest-likelihood operational risk here because it produces a total login outage. Require a synthetic per-provider login test in CI, covering both the happy path and failure paths, before considering any exposure.
- Is smorken/social-auth actively maintained, and what license does it use?
- The package shows no declared license in the supplied signals, which is a medium risk because unlicensed code can block commercial use. Last commit date and issue responsiveness are also unverified, and with no dependents the practical assumption is that you become the maintainer once you ship it. Budget ownership from day one, or fork it to an internal Git repository and wrap it behind an interface so swapping to native Socialite is a routine ticket.