Oauth 5 Laravel Laravel Package

Product Decisions This Supports

• Whether to ship social sign-in at all in an existing Laravel 5 app. This package is the cheapest possible way to answer "does 'Sign in with Google/Facebook' move our registration completion rate?" without a framework upgrade or a new identity vendor. It turns a multi-week OAuth 1.0a/2.0 handshake project into a config file plus a facade call.
• Build vs. buy for OAuth plumbing. The realistic comparison is not "this vs. Auth0" but "this vs. hand-rolled cURL + token handling." Choosing this package is a decision to buy (free OSS) the protocol boilerplate and own only the product surface: user provisioning, account linking, and session policy.
• Identity strategy scope. Because it is a thin client wrapper (a Laravel service provider around PHPoAuthLib, not an OAuth server), it forces an explicit decision that it will not give you SSO, MFA, user directory, or token issuance. Those remain separate roadmap items (Passport/Sanctum for issuing tokens, an IdP for enterprise SSO).
• "Connect your account" / delegated API access features. The same facade covers reading a user's profile, contacts, or posting on their behalf — so roadmap items like "import your LinkedIn network" or "publish to Twitter" can be prototyped on the same integration instead of a second one.
• Where identity work lands in the roadmap. It supports a "tactical now, strategic later" sequencing: ship social login this quarter behind an internal interface, defer the Laravel upgrade + Socialite migration to a planned platform initiative. That sequencing decision is the one this package most directly informs.
• Procurement and security-review posture. No vendor, no contract, no SLA, no CVE feed. That is a decision input for enterprise sales questionnaires and for whether identity becomes a compliance dependency. It should be logged as accepted technical debt with a named owner and a sunset trigger.
• Sunset trigger definition. A concrete PM decision this enables: "Migrate when we upgrade past Laravel 5.8, or when any provider deprecates the grant type we depend on, whichever comes first."

When to Consider This Package

Adopt when:

• You are on Laravel 5.0–5.8 / PHP 7.x and that constraint is real for the next 1–2 quarters.
• You need several providers behind one API, including OAuth 1.0a-era flows that Laravel Socialite core does not cover without extra drivers.
• Your need is narrow: obtain a token, fetch a profile, hand the identity to your own user model. You accept responsibility for token storage, refresh, and revocation.
• You have engineering capacity to pin the dependency and fork it internally if a provider changes an endpoint.
• The feature is experimental or non-critical-path — a growth test, an internal tool, a low-traffic B2C sign-up flow.

Look elsewhere when:

• You are starting a new build or already on Laravel 9/10/11. Use Laravel Socialite + SocialiteProviders — first-party, maintained, and the community drivers cover the long tail.
• You need PKCE, OIDC, Apple Sign In, refresh-token rotation, or provider-agnostic token lifecycle — modern requirements this wrapper was not built for.
• You need to be the OAuth server (issue tokens to third parties): that is Passport or Sanctum, not this.
• You need enterprise SSO (SAML/OIDC), SCIM provisioning, MFA, or audited identity events — buy an IdP.
• Identity is compliance-scoped (SOC 2, HIPAA, financial), or your customers will ask for a dependency-maintenance statement. An unmaintained wrapper around an unmaintained library will not survive procurement review.
• Your security policy forbids EOL framework versions — in which case the real decision is the framework upgrade, and this package is a symptom rather than a solution.

How to Pitch It (Stakeholders)

To executives — the one-liner: "A free, drop-in social login integration for our existing Laravel app. Days of work instead of weeks, no license cost, no new vendor — and it unblocks a measurable sign-up conversion test this quarter."

What it buys you: reduced registration friction (fewer form fields, no new password), higher completion on mobile sign-up, and a fast read on whether social sign-in is worth investing in properly. Cost is engineering time only; there is no contract to negotiate and no per-MAU pricing to model.

What it does not buy you: it is not an identity platform. No SSO, no MFA, no user directory, no vendor support, no security patch pipeline. It is a bridge, not a foundation.

To engineering: it is a thin service-provider wrapper over PHPoAuthLib — small surface area, easy to isolate. Mandate two things up front: (1) wrap it behind our own SocialAuthProvider interface so the swap to Socialite is a one-file change, and (2) pin the version and document the fork path. Treat token storage and user-account linking as our code, not theirs.

The risk we are accepting, stated plainly: we are adding a dependency that is itself a maintenance fork of an unmaintained library, on an end-of-life framework. That is acceptable as a deliberate, time-boxed bet — it is not acceptable as an undocumented default that quietly becomes load-bearing for three years.

The ask: approve as a tactical bridge with a named sunset trigger — "migrate at the next Laravel upgrade or the first provider deprecation, whichever comes first" — and fund the migration as a line item in the following platform cycle rather than discovering it under deadline pressure. Recommend a spike first if the roadmap already contains a framework upgrade within two quarters; in that case, go straight to Socialite and skip this step.