Laravelpassport Laravel Package

Product Decisions This Supports

• Multi-app SSO inside a Laravel estate. If your organization runs several Laravel applications — customer portal, admin console, partner-facing app, internal tools — and one of them already runs Laravel Passport as an OAuth2 server, this package lets every other Laravel app add "Sign in with [Your Platform]" through Socialite's standard Socialite::driver('laravelpassport') call. That converts a bespoke OAuth2 integration into a roughly ten-line addition per app.
• Make-or-defer IdP investment. Adopting this reinforces a Passport-as-IdP strategy for Laravel-to-Laravel traffic. That is cheap and fast, and it defers (or shrinks) a paid commitment to Auth0, Okta, WorkOS, Keycloak, or Cognito. The decision this package supports is "do we stretch Passport for another 12–18 months, or buy an IdP now?" — this package makes the "stretch" branch materially cheaper.
• Partner / B2B onboarding. If your roadmap includes exposing your Passport server to third-party or white-label Laravel apps, a Socialite driver is the lowest-friction onboarding path you can offer a Laravel shop. Non-Laravel partners still use standard OIDC/OAuth2, so this is additive.
• Build vs. buy vs. copy. The honest comparison is three-way: adopt this package, write your own ~100–150 line Socialite driver, or buy a hosted IdP. This package wins only in the narrow case of "small team, Laravel-to-Laravel, ship this quarter." For a team with platform capacity, vendoring a small internal driver is the stronger play — you get the same ergonomics with code you own and can patch. The 4.3.0 release slightly lowers the cost of the "vendor" branch (a fresher starting point to diff and fork) but does not change the recommendation to own the code.
• Architecture signals. The package's existence in your dependency graph is a leading indicator you are betting on Passport as the long-term identity backbone. Worth flagging explicitly in roadmap reviews, because reversing that bet later is expensive and touches every authenticated app. A single minor release after a long quiet period is not evidence of a renewed maintenance commitment — treat it as a one-off signal until a second, documented release lands.

When to Consider This Package

Consider adopting when:

• The identity provider you are integrating is a Laravel Passport server — this is the only case where the package is a natural fit.
• Both the client and the server are Laravel applications, and you want the same Socialite ergonomics your team already uses for GitHub/Google logins.
• The integration is first-party or low-sensitivity (internal admin tools, staging/demo environments, white-label instances, a small set of trusted partner apps).
• Your team is small enough that owning a custom Socialite driver is disproportionate maintenance.

Look elsewhere, or fork, when:

• You require maintained, security-reviewed dependencies. The signals remain weak despite the new release: roughly 62 stars, 0 dependents, and a 4.3.0 minor bump published after a quiet period since 4.2.0 (2022-08-11) with only an auto-generated changelog link and no described changes. A minor version number implies no breaking API change, but it tells us nothing about whether Socialite, PHP, or Laravel compatibility was actually modernized. An OAuth2 client is a security-surface component; a thin adapter that cannot demonstrably track Socialite/PHP/Laravel upgrades is still a liability. If you adopt it, vendor it into the repo and treat it as your code.
• You are on recent Laravel / Socialite versions. Socialite has had breaking changes across v5.x and PHP/Laravel majors. The 4.3.0 bump is a reason to re-run the compatibility check, not a substitute for it — assume nothing until you verify the install and a full token exchange against your exact dependency matrix.
• The counterparty is not a Laravel Passport server. If you are talking to a generic OIDC provider, use a maintained OIDC client — not this.
• You have platform engineering capacity. Writing the driver is small; the value of ownership (patching, telemetry, security review) usually exceeds the ~1 day saved by pulling this in.
• You need a real identity strategy. If you have SAML, SCIM provisioning, MFA policy, or enterprise SSO on the roadmap, Passport + this adapter will not carry you. Choose a proper IdP and skip this entirely.

How to Pitch It (Stakeholders)

To executives — one paragraph:

We can give every Laravel application we own a shared "sign in with us" experience at effectively zero license cost by reusing the Passport server we already run, rather than signing a hosted identity vendor. This is a low-risk way to defer six figures of IdP spend while we finish the multi-app roadmap. The connecting library was quiet for about two years and has just shipped a small version bump — a mildly encouraging sign, but not enough to treat it as an actively maintained dependency. Engineering would therefore own a copy of it internally rather than depend on upstream. That ownership cost is a day or two, not a project — which makes this a "yes for now," paired with a scheduled re-evaluation if we ever need enterprise SSO, MFA policy, or non-Laravel partners.

To engineering — the ask:

Evaluate this as a candidate to vendor, not a dependency to install. The new 4.3.0 release has no meaningful release notes, so start by diffing 4.2.0...4.3.0 to see whether anything material changed — dependency bumps, Socialite compatibility, or security fixes. Then run a spike that completes a full authorization-code exchange against our Passport server on our current Socialite/PHP/Laravel versions. If it works, copy the driver into our codebase, add tests, and pin it. If it does not, the fallback is to write the driver ourselves — the surface is small, and either way we end up owning the code. Please return an estimate that compares (a) vendoring versus (b) writing fresh, so we can choose on ownership clarity rather than convenience.

To security / platform review:

This introduces a client-side OAuth2 adapter maintained outside our control, with negligible community signal, that has just published a minor release (4.3.0) without a human-written changelog after a roughly two-year gap. We are not proposing to trust it as-is: we would fork it, diff the 4.2.0→4.3.0 change, review the token exchange and state handling, and run our own dependency scanning against the fork. Treat the fork as the unit of review, not the upstream package, and re-check upstream only if a documented, maintained release cadence emerges.