Http Hmac Php Laravel Package

Product Decisions This Supports

• Build vs. buy for service-to-service and partner API authentication. The package delivers a spec-driven HMAC-SHA256 signing and verification implementation (canonicalized headers, authorization-header builder, request/response signers, pluggable key providers, timestamp/nonce replay protection) with PSR-7 and Symfony request integrations. Adopting it removes an entire category of work — hand-rolled canonicalization and signature verification — that is easy to build and very easy to get subtly and insecurely wrong. For a PM, that is a build-vs-buy call worth making explicitly rather than defaulting to "we'll write it in a sprint."
• Scoping the real integration cost before committing roadmap. This is a library, not a Laravel package: no service provider, no config publish, no facade, no artisan surface. In Laravel terms the deliverable is our Guzzle middleware behind Http:: (or a dedicated Illuminate\Http\Client\Factory), plus a secret-management story. That means the roadmap item is "HMAC signing middleware + key rotation runbook," not "install package." Sizing it honestly prevents a one-point estimate turning into a three-point one.
• Runtime upgrade planning (PHP 8.4 / 8.5). Release 6.2.0 is an infrastructure and compatibility release: PHP 8.4 implicit-nullable deprecations silenced, minimum PHP raised 7.3 → 7.4, CI migrated from Travis/ORCA to GitHub Actions testing 7.4, 8.4 and 8.5. This is evidence the dependency is not an upgrade blocker and may in fact be a prerequisite for a clean 8.4 run — useful sequencing input for the platform upgrade epic.
• Dependency and security review inputs. Runtime requirements are unchanged: psr/http-message still accepts ^1.0 || ^2.0, so adoption does not force a PSR-7 major migration; Guzzle 7 is already the Laravel default client. Updated dev/suggested deps (Guzzle ^7.0, laminas-diactoros ^2.2 || ^3.0, symfony/security-bundle ^5.4, psr-http-message-bridge ^2.1 || ^6.4 || ^7.0, PHPUnit ^9.6) touch test tooling only. Small blast radius is exactly what a dependency-approval decision wants to see.
• Use cases it unblocks: signing outbound calls to HMAC-protected partner or Acquia-style endpoints; verifying inbound requests in middleware or at the edge; replay protection for webhook receivers. It does not replace Sanctum/Passport or provide OAuth2/OIDC/JWT — pairing it with Laravel's native guards remains a design decision we own.
• Roadmap signal, not a feature signal. There are no new capabilities in 6.2.0 — no new algorithms, no middleware, no Laravel service provider. If a product bet depends on new functionality, this release does not change the calculus; it only derisks keeping the dependency.

When to Consider This Package

Adopt when:

• We need standards-shaped HMAC request signing/verification and want a maintained implementation instead of owning crypto plumbing on the auth path.
• We are on or moving to PHP 7.4 through 8.5; 6.2.0 is explicitly tested across that range and clears the 8.4 nullable deprecations.
• Our HTTP stack is PSR-7/PSR-18 based (Laravel 9/10/11 with Guzzle 7 satisfies this out of the box) and we want to stay on psr/http-message v1 or v2 without a forced major bump.
• The integration surface is a small, well-defined set of endpoints that actually mandate HMAC — a bounded blast radius.
• We want the security-critical path owned upstream with public history and CI, narrowing our own review to configuration and key management.

Look elsewhere / proceed with caution when:

• We are still on PHP 7.3 or below. The floor is now 7.4 — the one genuinely breaking constraint here. Treat it as an upgrade prerequisite, not a footnote.
• We subclass the extension points. If our code extends AuthorizationHeaderBuilder, RequestSigner, ResponseSigner, HmacToken, HmacAuthenticationEntryPoint, or the Malformed*Exception classes, overrides need explicit ?Type nullable hints or they will still emit 8.4 deprecations — and become runtime failures wherever deprecations are promoted. Exception subclasses are the trap: they only run on error paths, so a green test suite proves nothing. Budget a grep-and-fix task.
• We expected framework-native auth primitives, an OAuth-style token flow, or a full OAuth2/OIDC/JWT authorization solution. This is request signing, not an auth framework.
• We need vendor-backed SLAs or commercial support; this is a community-maintained Acquia project with low release velocity and no Laravel-facing docs.
• Key management is ad hoc. The package signs correctly; secret storage, rotation across instances and regions, and clock-skew tolerance remain entirely ours — and that is where most real-world failures actually occur.
• PHP 8.0–8.3 is our target: the CI matrix covers 7.4, 8.4 and 8.5, so intermediate versions are covered by inference rather than explicit exercise.

How to Pitch It (Stakeholders)

For executives: This is a maintenance and compatibility milestone, not a feature drop — and that is the good news. The HMAC signing library behind our partner and service-to-service API authentication is actively maintained, has been brought up to date for PHP 8.4, and now runs its suite on modern CI across PHP 7.4, 8.4 and 8.5. That means fewer security-patch surprises, no forced rewrite of our request-signing layer, and one less blocker in the PHP upgrade plan. The trade-offs are small and known: our runtime floor moves to PHP 7.4, and any custom subclasses need a one-line-per-signature type-hint cleanup. The alternative — writing and owning signature canonicalization ourselves — carries materially higher security and maintenance risk for zero product differentiation. Worth being explicit that this is a library we integrate, not a turnkey Laravel feature: the middleware, secret rotation, and on-call runbook are our deliverables, so the cost sits in glue, not in the dependency.

For engineering: 6.2.0 is source-compatible for callers. Minimum PHP is now 7.4; psr/http-message remains ^1.0 || ^2.0, so no PSR-7 major bump, and Guzzle 7 is already our default. Implicitly nullable parameters now carry explicit ?Type hints — if we extend AuthorizationHeaderBuilder, RequestSigner, ResponseSigner, HmacToken, HmacAuthenticationEntryPoint, or the Malformed*Exception classes, mirror those nullables in our overrides to stay deprecation-free on 8.4. Dev/suggested dependencies have moved forward (Guzzle 7, laminas-diactoros 2.2/3.0, symfony/security-bundle 5.4, psr-http-message-bridge 2.1/6.4/7.0, PHPUnit 9.6) and may require lockfile updates in test tooling only. Two pre-existing hazards to retest at the same time: handler-stack ordering (signing must run after the body is finalized and before send) and deterministic body hashing on streamed or retried requests where the stream may already be consumed. Recommended sequence: inventory which endpoints genuinely need HMAC, pin ^6.2 on a branch, run the suite on 8.4 with deprecations surfaced, fix subclass signatures, canary one integration in staging with receiver-side verification on, then roll out per service — and only then schedule the 8.4 runtime upgrade, since 6.2.0 is a prerequisite for a clean run. Instrument the signer to log a hash of the canonical string and the key ID, never the secret.