Oauth User Data Laravel Package

Product Decisions This Supports

• Feature feasibility: Still not a viable dependency for a new Laravel social-login or profile-import feature. v1.0.1 is a narrow patch ("update to support new facebook requirements") to a concrete5-specific fork of an older Lusitanian/PHPOAuthLib extension. It fixes provider compatibility; it does not modernize the package, add Laravel integration, or add PHP 8+ / OAuth2-OIDC support.
• Roadmap priority: Keep out of the product roadmap except as a legacy-maintenance line item. Adoption signals (0 stars, 0 dependents) are unchanged, and a single reactive patch does not constitute a maintenance cadence. If anything, it confirms the package is kept alive only when an upstream provider breaks it.
• Build vs. buy: "Buy/reuse" remains indefensible for Laravel. Evaluate laravel/socialite plus provider SDKs or a maintained OAuth2/OIDC client. Use this package only as a reference for legacy concrete5 behavior — or, after v1.0.1, as a short-term compatibility bridge for an existing concrete5 install.
• Use cases supported: Legacy concrete5 OAuth profile extraction, including keeping an existing Facebook login working past a provider requirement change; migration archaeology. It still does not support new Laravel feature work, multi-provider profile normalization, token refresh, or modern OAuth2/OIDC requirements.
• Risk posture: Unchanged at high, with one nuance. The patch reduces immediate breakage risk for legacy concrete5 Facebook logins, but it also demonstrates the core problem: the package's lifecycle is dictated by external provider API changes (Facebook Graph API versioning), and each one requires a volunteer patch with no SLA, no CVE process, and no visible test/CI signals. Any production use still requires vendoring, patching, and security review.

When to Consider This Package

Consider it only when:

• You are maintaining an existing concrete5 application that already depends on this specific fork — and v1.0.1 is the release that unblocks a Facebook requirement change.
• You need to preserve legacy OAuth provider profile-extraction behavior during a migration.
• You have engineering capacity to vendor, patch, and audit abandoned PHP code.
• You can pin compatible PHP/runtime versions and accept reactive, unscheduled maintenance.

Look elsewhere when:

• You are building a new Laravel application or modern PHP service.
• You need PHP 8+ compatibility, active security maintenance, or OAuth2/OIDC compliance.
• You need multi-provider social login, token refresh, normalized user profiles, or provider SDK coverage.
• You require vendor support, CVE tracking, or a healthy dependency ecosystem.
• You are deciding between building and buying: prefer maintained framework-native options such as Laravel Socialite or provider-maintained SDKs.

How to Pitch It (Stakeholders)

Executive summary: This package is not a strategic dependency. It is a concrete5-specific fork with no adoption signals and no sustained release cadence. The new v1.0.1 release is a single compatibility patch for changed Facebook requirements — useful only to keep an existing concrete5 login from breaking. It does not change the strategic recommendation: do not adopt it for new Laravel product work. If a legacy concrete5 integration exists, isolate it, pin the patched version, document the dependency, and budget for replacement rather than extending it.

Engineering summary: Treat concrete5/oauth-user-data v1.0.1 as legacy reference/bridge code, not a forward-looking dependency. The patch updates Facebook handling against current provider requirements but leaves the underlying architecture unchanged: an older OAuth library wrapped for concrete5 conventions, with no Laravel integration and no active maintenance beyond reactive provider fixes. For Laravel, standardize on maintained OAuth/OIDC tooling and provider SDKs. For legacy concrete5, vendor and patch only if migration risk demands it — and assume further provider-driven patches will be needed that you may have to write yourself.