Laravel Socialite Mediawiki Laravel Package

Technical Evaluation

Architecture fit. This is a thin adapter, not a platform: a Laravel Socialite driver that maps MediaWiki's OAuth 2.0 endpoints onto Socialite's AbstractProvider contract and returns a standard Laravel\Socialite\Contracts\User. It slots into the existing Auth/Socialite layer without touching domain code, which keeps architectural blast radius small and makes the build-vs-adopt decision genuinely reversible. Fit is strongest where MediaWiki/Wikimedia identity is a primary IdP — Wikimedia-adjacent tooling (event dashboards, edit-a-thon sign-ups, campaign trackers), Toolforge front-ends, chapter/affiliate sites, internal wiki companion apps — or a deliberate secondary login alongside email/password. It is a poor fit as a generic "add a social login" package, because the addressable user base is anyone with an account on one specific wiki or wiki farm.

Integration feasibility. Mechanically trivial on the Laravel side: composer require, a credentials block in config/services.php, two routes, one controller. The real effort is wiki-side OAuth consumer registration through Special:OAuthConsumerRegistration, which yields client ID/secret and requires an exact callback URL match (scheme, host, port, trailing slash). As a TPM, plan the ticket around consumer registration and OAuth app governance, not PHP — that is where the calendar time goes, and it involves an external approver (a wiki bureaucrat) we do not control.

Technical risk. The risk profile is dominated by project health rather than code quality:

• Bus factor 1. Single maintainer, sourcehut-hosted, no GitHub issue tracker, no Dependabot or GitHub Advisory coverage. composer audit only sees the package if it is on Packagist and an advisory is filed through Packagist's feed.
• Zero external validation. 0 stars, 0 dependents means no downstream consumers exercising it against Socialite major bumps — we would be the first to discover breakage.
• Socialite coupling. Socialite has made breaking changes to AbstractProvider signatures across 5.x → 6.x (Laravel 11/12 era). Small packages like this frequently lag; verify the composer.json constraint range before committing to it inside a supported Laravel release.
• Identity semantics. MediaWiki OAuth profiles typically return a local sub, username, and groups — not email. On Wikimedia wikis, local user IDs are per-wiki; the stable cross-wiki identifier is the CentralAuth ID. Keying users on the wrong field creates duplicate accounts that are painful to merge later, and that is a product-data problem, not just a code one.
• Token capability. MediaWiki OAuth 2.0 has historically been authentication-oriented. Do not assume the returned token authorizes write actions via the Action API. If the roadmap includes editing or uploading on a user's behalf, that likely requires OAuth 1.0a with grants — a different implementation entirely.

Key questions to close before committing.

1. Is it published on Packagist, or must we add a VCS repository pointing at git.sr.ht? This drives CI availability and supply-chain exposure to a single forge.
2. Which Laravel/Socialite/PHP versions are declared and actually tested?
3. Is the wiki base URL configurable, or are Wikimedia endpoints hardcoded? This determines self-hosted MediaWiki support.
4. What does the profile payload actually contain, and which claim do we key on (local sub vs CentralAuth ID)?
5. What license applies, and is there any CI (builds.sr.ht) exercising the provider?
6. Does the token support authenticated Action API calls, or is it identity-only?

Integration Approach

Stack fit. Standard Laravel plus Socialite. No new runtime dependencies beyond laravel/socialite, no migrations, no service-container gymnastics. The only compatibility gate is the package's PHP constraint against our pinned PHP version and the Socialite version implied by our Laravel release.

Migration path. Additive, not a migration — there is no existing flow to displace. The one structural decision that matters: persist external identity in a dedicated social_identities table (user_id, provider, provider_user_id, raw_payload, timestamps) with a unique index on (provider, provider_user_id). That decouples our user model from this package and makes an IdP swap, or our own fork, a data-only change. Do not overload users.email — it will not be populated by this provider.

Compatibility. Three surfaces to verify: (a) Socialite major version against the package's declared constraint, (b) our wiki's MediaWiki/OAuth extension version and whether OAuth 2.0 is enabled, and (c) the consumer's registered callback URLs per environment. Staging and production need separate consumers or separately registered callbacks; this is the most common go-live failure and should be an explicit checklist item, not tribal knowledge.

Sequencing.

1. Spike (1–2 days). Register a dev consumer, wire the package in a branch, log the raw profile payload. This single artifact answers questions 3, 4, and 6 and de-risks the rest of the plan.
2. Vendor decision. Given roughly a few hundred LOC and zero dependents, plan to fork into an internal namespace immediately after the spike. Upstream becomes a reference, not a dependency. Treat this as the default, not a contingency.
3. Account linking. Build an explicit "link this wiki account to my existing account" flow, plus a first-login path that handles the no-email case (prompt for email or treat wiki identity as sufficient). This is a product decision that needs sign-off, not something an engineer should improvise in a controller.
4. Harden. Structured logging around the callback, explicit handling of InvalidStateException and provider Throwables, rate limiting on the redirect route.
5. Defer any write-to-wiki scope work until token capability is confirmed; scope creep into "edit on behalf of users" changes the technical shape of the project.

Operational Impact

Maintenance. Assume we own it. Budget a small recurring allotment: review on each Socialite major (roughly annually) plus a re-test when the target wiki upgrades its OAuth extension. Because there is no upstream community, "wait for a fix" is not a viable strategy — the fork is the strategy, and it should be staffed as such from day one rather than discovered in an incident review.

Support. No vendor, no GitHub issues, no Stack Overflow corpus. Internal documentation of the consumer registration process — who holds the secret, how it is rotated, which wiki bureaucrat approves consumers, what the exact registered callback URLs are — will be worth more than any code comment. Secret rotation is a manual, on-wiki operation with no API; assign a named owner and record it in the runbook.

Scaling. Negligible. This sits on the login path only: low QPS, no heavy computation, no caching concerns. Throughput ceilings, if any, come from the wiki's OAuth endpoints, not from us. Do not let it consume capacity-planning attention it does not deserve.

Failure modes to instrument. Each of these is a login-path outage, so the login callback failure rate should carry an alert rather than relying on user reports:

• Callback URL mismatch after a domain or canonical-host change — hard outage, invisible to users until they complain.
• Consumer secret rotation without an app redeploy — 401s at token exchange.
• Socialite major upgrade breaking AbstractProvider signatures — fatal at container resolution.
• Upstream wiki endpoint change or OAuth 2.0 deprecation.
• git.sr.ht unavailability breaking composer install in CI, if consumed via VCS repo rather than Packagist.
• Identity drift: a user renamed on-wiki, or keyed on a per-wiki sub that duplicates across wikis.

Ramp-up. Low. A Laravel developer with Socialite experience is productive in half a day. The wiki-side OAuth consumer process is the only unfamiliar territory and is a documented, one-time administrative task — worth pairing with whoever owns the wiki relationship, since that is the piece that will otherwise stall the ticket for a week while engineering waits on an external approver.

Bottom line for stakeholders. For a narrowly defined but valuable audience — people who already hold wiki accounts — this is a low-cost way to remove a signup barrier and meet users where they are. It is a contained integration, not a platform bet: if it does not work out, we can replace it without touching the rest of the product, provided we keep it behind our own auth abstraction and identity table from the start. What we are buying is days of engineering saved; what we are paying is a small permanent maintenance obligation and the diligence of the spike. Approve the spike, budget the fork, and gate the wider rollout on the identity-keying question being answered.