Hmac Bundle Laravel Package

Product Decisions This Supports

• API authentication strategy for partner and machine-to-machine traffic. HMAC request signing (shared secret → canonical string → signature header, plus timestamp/nonce) is the proven pattern for authenticating B2B integrations and service-to-service calls without shipping long-lived bearer tokens on every hop. This package is usable as a reference design for that decision, even though it is not something to adopt.
• Build vs. buy for request signing. The capability is narrow — sign a request, verify it, enforce a replay window. That narrowness is the decision input: the scope is small enough (~150–300 lines in Laravel, using hash_hmac, hash_equals, and a Redis nonce store) that owning an internal implementation is almost certainly cheaper than carrying a dependency. Zero stars, zero dependents, and a score of 0 reinforce the build side of that call.
• Webhook authenticity and replay protection on the roadmap. If outbound webhooks or inbound third-party callbacks are on the roadmap, the signing conventions here (canonical request construction, secret handling, timestamp + nonce replay defense) shape the contract you publish to integrators and the verification logic you ship to receivers.
• Key management and rotation requirements. The package exposes a single configured secret; production partner APIs need per-client keys and a kid-style rotation window. That gap is a product requirement to fund early, not a detail to retrofit after clients ship.
• Roadmap signal, not a feature commitment. Near-zero adoption means this is evidence that "this class of problem exists and has a standard solution," not evidence that this solution is production-ready. It should inform scoping, not trigger a dependency decision.

When to Consider This Package

Consider it only when:

• You are on an existing Symfony application — this is IbrowsHmacBundle, a Symfony bundle (a Bundle subclass plus a DI extension registered in AppKernel/bundles.php), not a Laravel package. It is only directly relevant if you have inherited it as a dependency and need to understand, audit, or replace it.
• You want a reading reference for header naming, canonical-string layout, and secret handling before writing your own implementation.
• You need a throwaway internal prototype where maintenance, security review, and upgrade paths are explicitly out of scope and no external party depends on it.

Look elsewhere, or build in-house, when:

• You are building on Laravel. Framework mismatch. Laravel does not boot a Symfony kernel and cannot consume a bundle; satisfying its symfony/framework-bundle requirement inside a Laravel app is not a viable path. Any "integration" is really a port of the signing logic into middleware and a service provider, after which the package is discarded.
• The work touches production security. Zero stars, zero dependents, and a score of 0 mean no peer review on security-sensitive code, no CVE visibility, and no disclosure channel. HMAC verification is exactly the kind of code that needs an owner, tests, and a reviewer who understands timing-safe comparison.
• You need long-term support. There is no release cadence, no advisories, and no upstream triage — you would be the sole maintainer by default, while still carrying the supply-chain surface.
• You target a modern stack. Assume compatibility gaps (likely pinned to PHP 5.x/7.x and Symfony 2/3/4 idioms — ContainerAware, non-hash_equals comparison, possibly weak default digests) until verified against PHP 8.2+/Symfony 6/7.
• You need multi-tenant keys. If the design requires a clientId → secret map with rotation, the single-secret configuration model does not fit.

How to Pitch It (Stakeholders)

To executives: This is an MIT-licensed implementation of HMAC request signing — a standard, well-understood way to authenticate server-to-server and partner API traffic. It is not a dependency we should adopt: no meaningful adoption, no visible maintenance, no security disclosure path, and it targets Symfony rather than our Laravel stack. The recommendation is to treat it as a design reference and fund a small internal implementation of the same pattern — roughly a day or two of engineering plus tests. That keeps security review, key rotation, and ownership in-house at negligible cost, and avoids converting a few hundred lines of code into a permanent fork-and-patch obligation. The real project cost is not the server-side code; it is client onboarding — signing docs and SDK snippets for integrators — and that budget is needed either way.

To engineering: Use it as a pattern reference, not a dependency. Read it for canonical request construction (method, path, timestamp, nonce, body digest), header conventions, and replay-window handling — then implement natively in Laravel: a Signer service, a VerifyHmacSignature middleware bound to a route group, hash_equals for comparison, raw-body hashing before request parsing, a kid header for key rotation, and Redis with TTL for the nonce store. Three things carry all the risk and deserve explicit decisions: (1) canonicalization — field ordering, encoding, duplicate and empty query params, empty and chunked bodies; mismatches here cause nearly all 401s; (2) fail-open vs. fail-closed when the nonce store is unavailable — default to fail-closed on write paths and document it; (3) route coverage — a test asserting every public route carries the middleware, so a route registered outside the protected group cannot silently bypass auth. Pin fixed sign+verify test vectors so any change to header names or field order breaks loudly. Roll out in shadow/log-only mode on one low-risk endpoint before enforcing. Also note the wire format only needs to match this bundle if we already run Symfony services that must interoperate — if not, standardize on our own documented scheme (Stripe/Svix-style) and implement once.