Laravel Passport Social Grant Laravel Package

Product Decisions This Supports

• Social/third-party login as a feature bet: this package is the glue that lets a mobile app or SPA authenticate with Apple/Google/Facebook and exchange that provider token for a first-party Laravel Passport access token. Adopting it is a "buy" decision that removes a bespoke token-exchange endpoint from your roadmap.
• Build vs. buy on identity: it settles the question of whether to hand-roll social token verification and OAuth token minting. Choosing this package means the team owns only the user-resolution logic (mapping a provider identity to a local User), not the grant plumbing.
• Multi-client / multi-platform roadmap: the 5.0.0 change — $client is now passed into resolveUserByProviderCredentials — is directly relevant if you plan to ship several first-party OAuth clients (iOS, Android, web, partner integrations). Resolution logic can now branch on which client is requesting the token, enabling per-platform user linking, client-scoped provisioning, or separate account namespaces without forking the package.
• Scope and risk planning for the upgrade: 5.0.0 is a breaking change to an extension point you are expected to implement. If you are already on 4.x, this is a scheduled engineering ticket, not a background dependency bump; if you are evaluating now, start on 5.0.0 and design the resolver signature accordingly.
• Security posture: delegating the grant to a maintained package keeps provider-token validation and Passport issuance out of your own code, reducing the surface area you must audit.

When to Consider This Package

Adopt it when:

• You already use Laravel Passport as your OAuth2 server and want social/provider-token login without replacing your auth stack.
• Your clients are native mobile apps or SPAs that obtain a provider token themselves (Apple Sign In, Google Sign-In, Facebook Login) and need to trade it for a first-party API token.
• You are comfortable owning a custom user resolver — the package deliberately does not decide how provider identities map to your users table, so account linking, email verification, and duplicate-account policy remain your product decisions.
• You can absorb a major-version upgrade cadence, since the resolver contract has now changed once in a breaking way.

Look elsewhere when:

• You are not on Passport (Sanctum, session auth, or a hosted identity provider such as Auth0/Cognito/Firebase Auth are different architectural bets — mixing them with this package adds complexity for no gain).
• You need provider-side flows the package does not own: refresh-token handling with providers, rich profile sync, webhook-driven deauthorization, or admin-facing account-linking UI.
• You want a batteries-included social login solution (e.g. Socialite plus a maintained starter kit) rather than a narrow grant type.
• Your compliance requirements (SOC2/ISO evidence, long-term support commitments) demand a vendor with an SLA; this is a single-maintainer community package.

How to Pitch It (Stakeholders)

To executives: This is a small, narrowly scoped open-source package that lets our Laravel API accept "Sign in with Apple/Google/Facebook" tokens from our apps and return our own access token, so we can ship social login without building or maintaining a custom authentication endpoint. It is a build-vs-buy call that saves roughly the engineering cost of one custom grant implementation plus its ongoing security upkeep. The trade-off is standard open-source risk: single maintainer, no SLA, and a major-version upgrade (5.0.0) that requires a small code change on our side.

To engineering: Version 5.0.0 is a breaking release — resolveUserByProviderCredentials now receives the Passport $client alongside the provider name and credentials. Any custom resolver must be updated to the new signature. In exchange, resolution logic gains access to the requesting OAuth client, which is the hook we would need for per-platform or per-tenant account handling. Recommended posture: adopt 5.0.0 directly for new work, budget a contained ticket to migrate existing 4.x resolvers, and keep our user-resolution logic thin and well-tested since it is the only part of this flow we own.