Oauth2 Linkedin Laravel Package

Technical Evaluation

Architecture fit. league/oauth2-linkedin is a thin provider adapter — a single class extending League\OAuth2\Client\Provider\AbstractProvider plus a resource-owner value object. It carries no runtime dependencies beyond league/oauth2-client, no framework coupling, no service container registration, no facades. For a Laravel codebase it is pure library code that you would wrap in your own service class or Socialite driver. The architectural surface area is negligible: five overridden methods (getBaseAuthorizationUrl, getBaseAccessTokenUrl, getResourceOwnerDetailsUrl, getDefaultScopes, createResourceOwner) and a handful of accessors. Practically, this is not a system you integrate; it is a system you copy.

Integration feasibility. Straightforward mechanically, but likely infeasible in production on the merits. The package's defaults target LinkedIn's legacy v2 surface: scopes r_liteprofile and r_emailaddress, and resource-owner retrieval against /v2/me with a follow-up call to /v2/emailAddress. LinkedIn's "Sign In with LinkedIn" products were superseded by Sign In with LinkedIn using OpenID Connect, which requires the standard openid profile email scopes and a GET /v2/userinfo call returning an OIDC-shaped payload. New LinkedIn applications cannot request the legacy products, so out of the box this provider will fail at the authorization step, not at the code step. Feasibility therefore hinges on how much of the class you are willing to override — at which point you are writing a new provider and using this repo only as a template.

Technical risk.

• Compatibility risk — high, realized. Last release 2020-04-20, predating LinkedIn's 2023 OIDC migration. The default scopes and resource-owner URL are stale.
• Maintenance risk — high. 87 stars, a single-maintainer-style package, no release in over five years. No expectation of an upstream fix.
• Data-model drift — moderate. The resource owner exposes legacy fields (firstName, lastName, headline, pictureUrls). OIDC's userinfo returns given_name, family_name, picture, sub, email_verified. Any mapping layer above this will need rework regardless.
• Supply-chain risk — low. MIT licensed, tiny code footprint, no exotic transitive dependencies, trivially vendorable and auditable. Ironically the deprecation risk makes the supply-chain risk almost irrelevant.
• Signal risk — moderate. "0 dependents" in this dataset is almost certainly an artifact of how dependents are counted for provider packages (most consumers depend on league/oauth2-client directly), but it does mean you cannot lean on a large installed base or downstream patch traffic as a safety net.

Key questions.

1. Is this for a new LinkedIn app or an existing one with grandfathered legacy product access? If new, the package as published cannot work.
2. Why not Laravel Socialite? Socialite ships a LinkedIn driver and has kept pace with the OIDC change; choosing this package means adding a second, parallel OAuth abstraction alongside Socialite or replacing Socialite entirely for one provider.
3. What is the actual required data set — identity only (sub, name, email, picture), or do we need LinkedIn organization/learning products that require separate API access anyway?
4. Do we need token refresh and token introspection, which this provider does not implement?
5. Is the team prepared to own a fork permanently, and does that fork live in-repo or as a private Composer package?

Integration Approach

Stack fit. Laravel already has an OAuth answer in Socialite; for a single provider, adding league/oauth2-client plus this provider duplicates the abstraction. The cleanest fit is to use Socialite's LinkedIn driver for the authorization-code dance, or — if Socialite is unavailable or undesirable — to fork this provider into app/Support/OAuth/LinkedInProvider.php and register it through a small Socialite::extend() call or a dedicated LinkedInClient service. Treat the repo as reference source, not as an installed dependency.

Migration path. If the dependency is already present, the migration is a replacement, not an upgrade:

1. Inventory every call site that resolves the provider and reads resource-owner fields (getFirstName, getEmail, getImageUrl, etc.) and map each to an OIDC claim.
2. Introduce a single domain-level LinkedInIdentity DTO with neutral fields (subject, email, emailVerified, givenName, familyName, pictureUrl). All application code moves to this DTO before any provider swap.
3. Swap the provider implementation behind that DTO — Socialite driver, forked provider, or a hand-rolled client — so the change is invisible above the DTO boundary.
4. Delete the league/oauth2-linkedin dependency and its lockfile entry once the last call site is migrated.

Compatibility. PHP version support should be verified against your runtime (the 2020 code was written for PHP 7.x; it will almost certainly run on 8.x, but no one has certified it). league/oauth2-client major-version drift is the real concern — the provider pins an old constraint, so Composer may force a downgrade of the client library across the whole application, which is a much wider blast radius than the LinkedIn integration itself. Check composer why league/oauth2-client before touching anything.

Sequencing.

1. Confirm LinkedIn app product access (OIDC vs. legacy) — this gates everything.
2. Freeze the dependency at its current version; do not attempt an in-place upgrade.
3. Build the LinkedInIdentity DTO and migrate call sites behind it (no behavior change).
4. Implement the OIDC-correct provider in parallel, feature-flag it, and validate against a staging LinkedIn app.
5. Cut over, monitor auth failure rates for one release cycle, then remove the package.
6. If any legacy app credentials still exist, run both paths briefly, then retire the legacy path on a known date.

Operational Impact

Maintenance. Assume zero upstream maintenance. The realistic maintenance unit is "one internal owner, a few hours per year" — provided the code is forked and small. Leaving it as an external dependency is worse operationally than forking, because you cannot patch a stale default scope without either a Composer patch plugin, a repositories override, or a wait that will never end. Budget for the fork explicitly.

Support. No vendor, no SLA, no security response channel beyond GitHub issues on a dormant repo. Escalation path is "read the source," which is viable here only because the class is ~200 lines. Document that the fork owner is a named engineer, not "the team."

Scaling. Auth volume is the wrong thing to worry about — LinkedIn OAuth is a low-QPS, user-initiated flow. The scaling concern is LinkedIn's rate limits and the extra round trip the legacy resource-owner logic performs (a second API call to fetch the email address). The OIDC userinfo endpoint returns identity and email in one call, so the migration is a net latency and quota win. Cache the resulting profile locally keyed on sub so re-logins do not require a fresh API call.

Failure modes.

• Authorization rejection due to unavailable legacy products — the most likely failure, presenting as an opaque invalid_scope error at the redirect. Detectable only at runtime; requires a smoke test in CI against a real LinkedIn app, not a mock.
• Silent identity regression — a provider swap that leaves email empty because the claim name changed from emailAddress to email. Enforce a non-null invariant on LinkedInIdentity::email at construction.
• Token expiry / no refresh path — the provider does not handle refresh; users with long-lived sessions will hit re-auth more often than expected. Acceptable for login-only use, blocking if you plan to call LinkedIn APIs on the user's behalf later.
• Dependency resolution conflict — a forced downgrade of league/oauth2-client breaking an unrelated integration. Mitigate with composer why before install, and pin.
• Abandoned-package scanner noise — expect this to surface in SCA and dependency-health reporting indefinitely; pre-empt the audit question with a written rationale.

Ramp-up. Low for any Laravel engineer familiar with OAuth: the class is small and idiomatic, and Socialite/League patterns are widely understood. The real ramp-up cost is LinkedIn-side, not code-side — app verification, product access requests, redirect URI registration, and understanding which scopes your app is actually entitled to. That work is measured in days of calendar time and is the same regardless of which library you pick, which is precisely why the library choice should not be the long pole. Recommendation: do not adopt as a dependency; use as a reference implementation, ship an OIDC-correct provider behind your own DTO, and revisit only if the upstream repo publishes an OpenID Connect release.