Oauth User Data Laravel Package

Product Decisions This Supports

• Social login / OAuth onboarding scope: Deciding whether to standardize user-profile ingestion (email, name, avatar, provider user ID) behind a single adapter layer instead of writing provider-specific mappers for Google, Facebook, Twitter, etc.
• Build vs. buy for the auth surface: Evaluating whether a thin open-source extension over an OAuth client is cheaper than building and owning provider integration code. This package is a "buy" candidate only in the narrow sense of reusing an existing abstraction; it is not a standalone auth product.
• MVP acceleration and legacy fit: If the product already sits on Lusitanian/PHPoAuthLib, this reduces effort to normalize heterogeneous provider payloads into a user model — a real time-saver for prototypes, internal tools, or legacy integrations.
• Roadmap / technical-debt triage: With a 2014-02-10 last release, 44 stars, 0 dependents, and a low opportunity score, the primary decision it informs is whether to depend on abandoned OAuth abstractions at all. For new work, it argues for migrating to maintained alternatives (Laravel Socialite, league/oauth2-client, or a managed IdP) rather than extending this.
• Risk gating for compliance and security: Informs whether profile-data handling can rely on an unmaintained dependency, which matters for any path touching PII, account takeover, or audit requirements.

When to Consider This Package

Consider it when:

• You are already committed to Lusitanian/PHPoAuthLib in a legacy codebase and want minimal-change profile extraction.
• The scope is a prototype, internal tool, or non-critical integration where you accept forking and self-maintenance.
• You need a small, MIT-licensed normalization layer and are prepared to own security patches, PHP version bumps, and provider API drift yourself.
• You have a vendoring/pinning strategy and a documented upgrade path off it.

Look elsewhere when:

• You are starting a new Laravel build — use Laravel Socialite; it is the idiomatic, maintained choice.
• You need modern OAuth2/OIDC flows — use league/oauth2-client with maintained provider packages.
• The feature is security-sensitive (login, account linking, PII ingestion), where unmaintained dependencies are a liability.
• You require PHP 7.4+/8.x support, active releases, CVE response, or vendor support.
• You need enterprise SSO, MFA, or directory sync — that is a managed-IdP decision (Auth0, Clerk, WorkOS, Okta), not a package decision.
• Your procurement or security review disallows dependencies with no recent releases and no dependents.

How to Pitch It (Stakeholders)

One-liner: A small MIT-licensed helper that pulls user-profile data from OAuth providers on top of Lusitanian/PHPoAuthLib — useful historically, but effectively frozen since 2014.

For executives: This is a build-vs-buy input, not a product. It is low-cost to evaluate and high-risk to depend on: last release 2014, 44 stars, zero dependents, and no maintenance signal. We should not anchor new authentication or user-onboarding work on it. If it is already in the stack, treat it as technical debt with a planned migration to a maintained library or managed identity provider.

For engineering: The abstraction (normalizing provider profile shapes) is sound, but the surrounding client stack is stale and the ecosystem has moved to Socialite and league/oauth2-client. Reusing it means owning provider API changes, PHP compatibility, and security patches ourselves. Recommendation: do not adopt for net-new features; if used, fork, pin, isolate behind our own interface, and schedule replacement. This keeps the migration cheap and avoids locking profile handling into an unmaintained dependency.