Ouath2 Merchant Laravel Package

Technical Evaluation

Architecture fit. salla/ouath2-merchant is a thin, well-scoped adapter rather than a platform. It does two jobs: (1) implement a league/oauth2-client provider for Salla's authorization server, and (2) ship Laravel glue — a SallaOauth facade, a salla-oauth guard, and a salla.oauth[:scopes] bearer-token middleware that resolves the caller by round-tripping to accounts.salla.sa/oauth2/user/info and caching the result. For any Laravel service acting as a resource server for Salla merchant storefronts/apps, this is the correct shape: it slots into the existing auth stack instead of inventing a parallel one. The hard dependency on league/oauth2-client means the OAuth mechanics are a commodity you inherit, and your surface area is the Salla-specific glue — which is exactly where you want the coupling to be.

Integration feasibility. High. Composer-installable, MIT, PHP ^8.1, illuminate/support ^9–^13, so it spans Laravel 9 through 13 — a wide and currently supported window. The middleware is opt-in by alias, so adoption is incremental and reversible per-route. The facade gives you a low-ceremony escape hatch for scope-specific token acquisition. Testability is good: the documented pattern of stubbing fetchResourceOwnerDetails means auth can be faked in feature tests without hitting Salla.

Technical risk. Three real flags:

1. The package name is misspelled (ouath2), and the guidance explicitly forbids renaming it without auditing consumers. That typo is now load-bearing across PartnerMarketing, DevelopersPortal, apps-marketplace-api, Experts, zatca-einvoicing, zoho-connect, and Foodics-App. Any future "cleanup" is a coordinated multi-repo Composer migration, not a patch. Budget for it or accept it permanently.
2. Bearer tokens in cache keys. The middleware caches user info keyed by the raw access token, and the team is warned not to log cache keys. That is a strong signal of a latent secret-exposure path: Redis MONITOR, slow-log, key dumps, or an errant Log::info($key) all leak live credentials. Hashing the token for the key is a small, backwards-compatible hardening change — I would request it before broad rollout.
3. Per-request upstream dependency. Scope validation costs a network call to accounts.salla.sa on cache miss. That is a hard external dependency in your auth hot path, and it inherits Salla's availability and latency.

Secondary risks: no published dependents (25 stars) means the community signal is essentially nil — you are relying on first-party internal consumers for validation, which is fine but means you should treat the package as "internal with a public face," not as a vendor-supported library. phpcs PSR-2 is not enforced in CI, so style drift is possible but low-impact.

Key questions.

• Is the raw-token cache key a deliberate design choice or an accepted shortcut? What is the exposure window and rotation story if a Redis instance is breached?
• What is the cache TTL, and how is revocation handled? A revoked Salla token will keep passing middleware until expiry unless there is explicit invalidation.
• Is the package versioned and released under a policy we can depend on (3.0.x, manual tags), or do we need to pin to commit SHAs?
• Does Salla publish a token introspection or JWKS endpoint that would let us validate locally and drop the per-request round trip?
• Who owns the package internally, and what is the SLA for a Salla API breaking change?

Integration Approach

Stack fit. Excellent for Laravel 9–13 on PHP 8.1–8.3. The illuminate/support constraint is the deciding factor — if any target service is on Laravel 8 or PHP 8.0, it is out of scope and needs a separate path. Confirm the PHP floor across the estate before committing. Non-Laravel PHP services can still use the league/oauth2-client provider directly and forgo the middleware/guard, which is a reasonable degraded mode.

Migration path. Adoption is additive, not a rip-and-replace:

1. Add the dependency and register the service provider.
2. Configure client ID/secret and redirect URI per environment; secrets go to the secret store, never .env committed or repo (explicitly called out in the guidance).
3. Apply the salla.oauth[:scopes] middleware to routes that accept Salla-issued bearer tokens; leave everything else untouched.
4. Optionally wire the salla-oauth guard for Auth::guard() ergonomics.
5. Read the resolved identity from the salla.oauth.user request attribute.

Because it is route-scoped, you can land it on one endpoint, observe, and expand. No data migration, no schema change, no client cutover.

Compatibility. The middleware alias (salla.oauth), guard name (salla-oauth), request attribute (salla.oauth.user), and cache payload shape are all public contracts with existing consumers. Treat them as frozen. Upgrades within 3.0.x should be safe; a 4.x major is where breaking change risk concentrates, and that is the moment to renegotiate the misspelled package name if you ever intend to.

Sequencing. I would order it: (a) pin and audit the package in one low-traffic service; (b) verify cache behavior under load and confirm the token-in-key concern is contained; (c) harden (hashed keys, explicit TTL and revocation policy); (d) roll to the remaining services; (e) only then consider the rename as a separate, scheduled, multi-repo project with a deprecation shim on Packagist.

Operational Impact

Maintenance. Low ongoing cost, with one caveat: the package is maintained by Salla (or Salla-adjacent maintainers) with manual semver tags and a master default branch. There is no public ecosystem to catch regressions, so your own CI is the safety net. Expect to own the pin and upgrade cadence yourself rather than waiting on a security advisory feed. The typo'd name means any future hygiene work is a cross-team coordination cost, not a solo PR.

Support. Effectively first-party-internal. With 25 stars and no published dependents, community support is not a realistic channel — you escalate to whoever owns the package internally. Document that owner and the escalation path alongside the integration; a bus-factor of one on an auth dependency is a real operational risk.

Scaling. The library itself is stateless and cheap. The scaling story is entirely about the cache in front of accounts.salla.sa/oauth2/user/info:

• Cache hit path is a Redis lookup — sub-millisecond, scales horizontally without thought.
• Cache miss path is a synchronous external HTTP call inside your auth middleware. Under a cold cache or a thundering herd (mass token rotation, deploy flush, Redis failover), you will fan out to Salla's accounts service at request rate. That is the throughput ceiling of the whole integration.
• Mitigations worth pre-building: negative caching for invalid tokens, single-flight/dogpile protection on miss, a circuit breaker with fail-closed behavior, and a short jittered TTL. If Salla exposes JWKS or introspection, local validation removes this dependency entirely and is the highest-leverage scaling improvement available.

Also note the Redis dependency is explicit in the CI matrix — plan for Redis as a hard runtime requirement in every adopting service, not an optional cache.

Failure modes.

The revoked-token window is the one I would surface to security explicitly: the cache converts an instant revocation into a TTL-length grace period, and that must be a conscious, documented accepted risk with a defined TTL.

Ramp-up. Fast — a Laravel engineer who has used league/oauth2-client before is productive in hours, not days. The friction is not the API but the institutional knowledge: the frozen contracts, the master branch and manual release process, the mock-by-stubbing test pattern, and the raw-token cache key. Put those four items in an onboarding note and the ramp-up is genuinely trivial. The broader org-level ramp-up — eight-plus consuming services, a shared auth contract, and a naming mistake baked into every one of them — is where the real cost sits.