Oauthclient Laravel Package

Technical Evaluation

Architecture fit

• Purpose-built for one job: the OAuth 1.0a three-legged handshake against a MediaWiki wiki running Extension:OAuth, plus an identify call to resolve the authenticated wiki user (username, blocked flag). Exposed surface is small and stable: ClientConfig, Client, Consumer, Token, User.
• Framework-agnostic PHP with no Laravel coupling — it is a library, not a package. That is a feature (no version lock to Laravel internals) and a cost (we own all the glue: config, service provider, routes, token persistence).
• Wrong shape for "generic social login." Laravel Socialite is OAuth 2.0-first and has no first-party MediaWiki provider; MediaWiki's long-standing OAuth extension is OAuth 1.0a. This library is the pragmatic bridge, but it means Socialite's driver/stateless abstractions don't apply — we hand-roll the request-token → authorize → callback → access-token flow.
• Correct fit only if the product genuinely needs either (a) "Sign in with Wikipedia/our wiki" identity, or (b) delegated on-wiki actions (edits, uploads, page moves) on behalf of a user without storing their password.

Integration feasibility

• Low technical difficulty, moderate packaging friction. Wrap it in a MediaWikiOAuthService resolved from the container, a config/mediawiki-oauth.php for consumer key/secret and wiki base URL, and two controller actions. The real work is the OAuth 1.0a request-token secret: it must survive a browser redirect, so it belongs in a shared session/cache store — not a per-node in-memory or file session — or the callback fails intermittently behind a load balancer.
• Runtime dependency is the friction point: the library expects the PECL oauth extension. That is not in stock php:fpm images and must be added to every Dockerfile/AMI, including CI and local dev. Budget for that explicitly; it is the most common "works on my machine" failure.
• Access tokens issued by MediaWiki OAuth are long-lived credentials. They need encrypted-at-rest storage, a revocation path (users can revoke at Special:OAuthManageMyGrants), and a re-auth prompt when identify returns 401.

Technical risk

• Staleness (high). Last release February 2019. Code predates PHP 8; expect no declared ^8.x support and possible deprecation noise (dynamic properties, implicit nullable parameters). A one-day compatibility spike on our target PHP version is mandatory before committing.
• Protocol risk (high). Wikimedia has been steering consumers toward OAuth 2.0; OAuth 1.0a is legacy for new registrations. Building on 1.0a now means a probable migration within the product's lifetime. Confirm the target wiki's supported grants before design sign-off.
• License (medium-high). GPL-3.0. Fine for GPL-compatible or internal-only deployments; a genuine problem if we ship a closed-source product or appliance that bundles it. Get a legal read before this enters the dependency graph — retrofitting is expensive.
• Adoption signal (low but misleading). 12 stars and 0 Packagist dependents looks alarming, but the effective consumers are Wikimedia's own Toolforge tools that don't register on Packagist. Treat it as "narrow, Wikimedia-maintained utility," not "abandoned toy" — and equally, not as a library with a broad bug-finding surface.
• Bus factor (medium). Effectively one maintainer inside WMF. If it breaks, we fork.

Key questions

1. Which wiki(s)? Wikimedia production (meta.wikimedia.org) or an internal/enterprise MediaWiki farm? Registration, approval, and rate-limit regimes differ materially.
2. Identity only, or delegated write? Write access raises grant scoping, rate limits, and abuse-handling requirements.
3. Is OAuth 1.0a still available for new consumers on the target wiki, and what is its deprecation horizon?
4. Is our application distributed to third parties? (Determines whether GPL-3.0 is a blocker.)
5. Can we ship the PECL oauth extension across all environments, including managed hosting or PaaS where we cannot install PHP extensions?
6. Do we need Socialite-style multi-provider login, or is MediaWiki the only identity source?

Integration Approach

Stack fit

• Works on any Laravel version because it touches nothing in the framework. The constraint is PHP/ext-oauth, not Laravel.
• Two viable shapes:
  • Direct: library + thin service wrapper + two routes. Lowest ceremony, best if MediaWiki is the only provider.
  • Socialite driver: implement a custom Socialite provider or adopt a community MediaWiki provider to keep one auth abstraction. Only worth it if we already run Socialite for other providers; otherwise it adds a layer with no payoff.
• Keep the library behind an interface (WikiAuthContract) from day one. That is what makes the eventual OAuth 2.0 migration or a fork a swap rather than a rewrite.

Migration path

• No migration needed for greenfield.
• If replacing password/BotPassword-based bot integrations: this is a net security improvement (no stored wiki passwords, per-user delegation, user-revocable grants). Sequence it as a parallel auth path first, then retire credential storage.
• If we later move to OAuth 2.0, the seam is the contract: getAuthorizationUrl(), completeAuthorization(), identify(). Keep those three methods free of OAuth 1.0a types so the implementation can change without touching controllers.

Compatibility

• Verify against our PHP minor version in a throwaway branch: install, run the handshake against a test consumer, parse the identify response.
• Pin the dependency exactly; do not float. If the php constraint blocks install, use a composer.json platform override only after the runtime spike passes, or vendor-fork under our namespace and drop the guard.
• Validate the wiki's extension version and available grants; older MediaWiki releases predate some grant semantics.

Sequencing

1. Spike (1–2 days): register an owner-only consumer at Special:OAuthConsumerRegistration, complete handshake from a Laravel route on target PHP, confirm identify returns the expected user payload. This answers compatibility, protocol availability, and extension availability in one pass.
2. Legal/licensing read on GPL-3.0 in parallel with the spike — cheapest point to abandon.
3. Wrap: config, service provider binding, WikiAuthContract implementation, encrypted token model and migration.
4. Auth flow: redirect + callback routes, CSRF/state-equivalent handling, user association, re-auth on revoked token.
5. Grant-scoped API client if write actions are in scope — rate limits, maxlag, and error taxonomy handled centrally.
6. Operationalize: PECL extension in images, secret rotation procedure, revocation/admin tooling, structured logging around auth failures.

Operational Impact

Maintenance

• Low ongoing code churn (the protocol is frozen), high latent risk (no upstream activity since 2019). Assume we own the code for planning purposes.
• Mitigation: vendor-fork into our namespace on adoption, add PHP 8 CI and a handshake integration test, and record the fork point. Cost is a few hours; it converts an unmaintained dependency into a controlled one.
• Track two external signals: PHP version support in our runtime, and MediaWiki's OAuth 1.0a deprecation announcements.

Support

• No commercial support; upstream issues go to Wikimedia Phabricator. Debugging will be on us.
• Internal support burden concentrates on two runbooks: "callback fails / invalid signature" and "token revoked by user." Both recur and both are user-visible.

Scaling

• The library itself is a non-issue: stateless signed HTTP calls, no DB, linear cost per auth event.
• Real scaling levers are elsewhere:
  • Shared session/cache for request tokens (breaks first under horizontal scaling if ignored).
  • MediaWiki API rate limits and maxlag compliance for write-heavy usage — Wikimedia applies per-consumer limits and will throttle or block abusive consumers.
  • Token store growth and encryption key management; key rotation needs a re-encryption path.

Failure modes

• Lost request token (multi-node sessions, cache eviction): intermittent callback failures that appear under load only. Design for it up front.
• Clock skew: signatures rejected with mwoauth-invalid-authorization. Needs NTP discipline and a clear error message rather than a generic 500.
• Revoked/expired grants: identify returns 401; must trigger re-consent, not a dead end.
• Missing PECL extension in a new container image or a scaled environment: hard failure at class load, caught only if CI runs the handshake.
• Wiki-side changes: extension upgrade altering grants or endpoint behavior; read-only/maintenance windows during scheduled Wikimedia maintenance.
• Consumer approval gates: non-owner-only consumers on Wikimedia require community review before use — a schedule risk, not a technical one. Start registration early.
• License contamination discovered post-launch in a distributed build — the most expensive failure mode and the easiest to prevent.

Ramp-up

• Small surface: a competent Laravel developer is productive in half a day; the entire API is five classes.
• The learning is not the library — it is (a) OAuth 1.0a signature mechanics and why the token secret must round-trip through the session, and (b) the wiki-side consumer registration and grant-scoping workflow, which is bureaucratic rather than technical.
• Plan knowledge transfer to at least two engineers; single-owner knowledge of an unmaintained, security-adjacent dependency is the compounding operational risk here.