Ouath2 Merchant Laravel Package

Product Decisions This Supports

• Build vs. buy on the OAuth layer. This is effectively the "buy" (or rather, "adopt") answer for authenticating against Salla merchant stores. Anything you'd hand-roll — authorization code exchange, token refresh, resource-owner lookup, bearer-token middleware, a Laravel guard — is already here on top of league/oauth2-client. Building it in-house is only justified if you need grant types or flows it doesn't expose.
• Marketplace/app-store entry decisions. If a roadmap item is "be installable in Salla's App Market," this package plus a registered app is the minimum viable plumbing. It de-risks the "can we even integrate?" question before you commit engineering to the differentiating feature.
• Multi-tenant architecture choices. The salla-oauth guard and salla.oauth[:scopes] middleware give you a per-request merchant identity (salla.oauth.user request attribute) — that's the anchor for deciding how you model tenants, store tokens, and scope data access. Decide early whether you persist merchant identity yourself or rely on the per-request lookup.
• Scope strategy per endpoint. The :scopes parameter on the middleware makes authorization granularity an explicit, reviewable product decision rather than an implicit one. You can ship a read-only feature on narrow scopes and widen later without re-architecting.
• Latency vs. revocation freshness tradeoff. The middleware validates tokens against accounts.salla.sa/oauth2/user/info and caches the result. That cache TTL is a product lever: shorter means faster revocation on uninstall/suspend, longer means fewer round-trips and better p95. Pick it deliberately per surface (checkout-adjacent flows vs. back-office dashboards).
• Roadmap sequencing for the integration layer. Because illuminate/support ^9–^13 is supported, this doesn't pin your Laravel upgrade cadence. That removes a common blocker from upgrade planning.
• Buyer/user segmentation. Delegated access means you never touch merchant credentials — a compliance and trust story you can put in security reviews and merchant-facing docs, not just a technical detail.

When to Consider This Package

Adopt when all of these hold:

• You are building a Laravel (9–13) or plain PHP 8.1+ application that acts as a client to Salla merchant stores.
• You need delegated, per-merchant authorization — not a single shared API key.
• You want a ready-made guard and middleware rather than writing token introspection and caching yourself.
• Your team can accept a single-vendor, low-external-adoption dependency (25 stars, 0 public Packagist dependents) that is maintained upstream by Salla for its own partner ecosystem.
• You're comfortable that the release process is manual semver tagging on master (currently 3.0.x), so you should pin versions and read changelogs rather than float.

Look elsewhere or pause when:

• You aren't integrating with Salla. Nothing here generalizes; use league/oauth2-client directly or Laravel Socialite for other providers.
• You need a server, not a client. This is an OAuth client library. If you're issuing tokens to others, you want Laravel Passport or Sanctum.
• You need the full integration surface. Webhook signature verification, order/product APIs, and rate-limit handling are not in scope here. Budget separately for an API client layer.
• You require a vendor with public SLA/support commitments. There is no commercial support tier implied. MIT licensing means you can fork, but you own the maintenance if upstream stalls.
• You're pre-PHP 8.1 or on Laravel 8. No support; don't backport.
• The package-name typo (ouath2) is a blocker for your supply-chain or procurement review. Worth raising early — the misspelling is real, it hurts discoverability, and a near-miss name is a typosquatting surface. Renaming is impractical because internal consumers depend on the Composer name, so plan to live with it and mitigate via pinned hashes/lockfiles rather than asking for a rename.

One operational caveat to bake into your definition of done: cache keys contain the raw bearer token. Any logging, APM, or debug-dump configuration that could emit cache keys is a credential-leak path. Treat that as a security acceptance criterion, not a code-review nit.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed library that lets our product securely connect to Salla merchant stores using standard OAuth 2.0 delegated access — merchants authorize us, we never handle their passwords. It's maintained by Salla for its own partner ecosystem, so it stays aligned with their platform, and it's compatible with our current Laravel and PHP versions, meaning no upgrade tax. Adopting it removes several weeks of authentication plumbing from the Salla integration and lets us spend that effort on the features customers actually pay for. The main risk is concentration: it's a single-vendor dependency with limited public adoption, which we mitigate by pinning versions and keeping our integration thin enough to fork or replace.

To engineering: It's a thin, well-scoped wrapper around league/oauth2-client plus Laravel glue: a SallaOauth facade, a salla.oauth[:scopes] bearer-token middleware that validates against accounts.salla.sa/oauth2/user/info with caching, and a salla-oauth guard that exposes the merchant as a request attribute. PHP ^8.1, Illuminate ^9–^13, PHPUnit via Testbench, CI on 8.1–8.3. Two constraints to design around: don't rename the package, guard, middleware alias, request attribute, or cache payload shape — seven internal services depend on those names — and never log cache keys, since they contain the raw bearer token. Treat the introspection cache TTL as a security-relevant configuration value, pin the version, and keep our Salla-specific code isolated behind an interface so a fork or replacement stays a contained change.