Product Decisions This Supports
- Feature scoping — "Log in with MediaWiki" as a first-class auth path. For products serving wiki contributors, this package turns a multi-day OAuth integration into a few lines of Socialite configuration. It shifts the question from "can we afford to support wiki SSO?" to "is this audience worth a small, contained integration?"
- Roadmap sequencing around an identity our users already own. Relevant when the audience holds MediaWiki accounts — Wikipedia editors, Wikimedia movement affiliates, edit-a-thon and campaign participants, staff in organizations running private wikis. It lets us sequence onboarding around an existing identity instead of forcing yet another account.
- Build vs. adopt vs. fork. The provider is thin and narrow; the real decision is "adopt an existing Socialite driver" vs. "write and maintain the OAuth handshake ourselves." Adopting shifts maintenance to a third party — but with 0 stars and 0 dependents, the honest framing is adopt-then-own: budget to fork it into our own namespace after a short spike.
- Use cases to validate against: Wikimedia-adjacent tooling (event dashboards, edit-a-thon sign-ups, campaign trackers), Toolforge tool front-ends, internal wiki companion apps, community platforms for editors, and SSO for staff/volunteers in MediaWiki-running organizations.
- Friction and account duplication reduction — for a specific segment. SSO against MediaWiki consolidates identity for wiki-native users and improves activation for that segment. It is not a general consumer growth lever, and we should not pitch it as one.
When to Consider This Package
Consider it when:
- Your target users are MediaWiki account holders, you're building on Laravel, and "sign in with your wiki account" is a meaningful onboarding path — not a checkbox.
- You want a small, replaceable integration and can accept a single-maintainer dependency with no adoption history. Treat it as a starting point you may need to fork or patch, not a battle-tested vendor component.
- You're willing to spend the diligence up front: which OAuth version it targets (MediaWiki's OAuth extension), license, test coverage, declared Laravel/Socialite/PHP constraints, whether the wiki base URL is configurable, and what the profile payload actually returns.
Look elsewhere (or build directly) when:
- Your audience isn't wiki-centric — Google, Okta, Auth0, or a generic OIDC provider will serve you better with far less maintenance risk.
- You need broad identity, MFA, SCIM, or enterprise SSO — this is a single-provider Socialite driver, not an identity platform.
- You need fine-grained control over scopes, callback handling, or token refresh beyond what the driver exposes; implement the OAuth client directly against MediaWiki's API instead.
- Dependency health is a hard requirement. With no stars and no dependents there is no community buffer — plan to own the code, and keep the integration behind an interface so swapping it out is cheap.
- The roadmap includes writing to the wiki on a user's behalf (edits, uploads). MediaWiki OAuth 2.0 is authentication-oriented; that capability likely requires OAuth 1.0a with grants — a different implementation entirely.
How to Pitch It (Stakeholders)
To executives: For a narrowly defined but high-value audience — people who already have wiki accounts — this is a low-cost way to remove a signup barrier and meet users where they already are. It's a small, contained integration, not a platform bet. The upside is activation for that segment; the risk is maturity, and the mitigation is that we can replace it without touching the rest of the product. Recommend a short spike before any commitment, with the option to fork and own the code at trivial cost.
To engineering: It's a thin Laravel Socialite provider for MediaWiki OAuth — minimal surface area, easy to read, easy to fork. Mechanically it's composer require, credentials in config/services.php, two routes, and a callback. The real work is on the wiki side: registering an OAuth consumer via Special:OAuthConsumerRegistration with an exact callback URL match, and doing it separately per environment. Expect to spend most of the ticket there.
The tradeoffs to flag: essentially no adoption history, so we should pin the version, wrap it behind our own auth abstraction (a social_identities table keyed on (provider, provider_user_id)), and verify Socialite major compatibility, declared Laravel/PHP constraints, configurable wiki base URL, and what claim we key on — local sub is per-wiki, so Wikimedia's stable cross-wiki identifier is CentralAuth. Profiles typically return username and ID but not email, so the first-login flow needs an explicit answer for that. Instrument the callback failure rate as a login-path alert; the common go-live failures are callback URL mismatch, secret rotation without redeploy, and a Socialite upgrade breaking AbstractProvider signatures. Effort is small; the diligence is the real cost.