uma/psr7-hmac
PSR-7 HMAC authentication for PHP. Sign and verify HTTP requests with a shared secret, adding tamper-proof request signing to APIs and service-to-service calls. Framework-agnostic, PSR-15 middleware-friendly, and lightweight to drop into any PSR-7 stack.
Architecture fit. uma/psr7-hmac sits on PSR-7 HTTP message abstractions, while Laravel’s inbound request/response pipeline is built on Symfony HttpFoundation (Illuminate\Http\Request). That is a real impedance mismatch: using the package for inbound HMAC verification would require a PSR-7 bridge, raw-body capture before Laravel parses the request, and careful middleware ordering. For outbound server-to-server request signing, the fit is better because Laravel’s HTTP client is Guzzle-backed and can accept Guzzle middleware/handler-stack customization. The package is therefore more plausible as a reference implementation or outbound signing helper than as a native Laravel auth middleware.
Integration feasibility. A proof of concept is feasible under MIT licensing, but production adoption as-is is weak. The package is archived, last released 2020-12-26, has 23 stars and zero dependents. Those are low ecosystem-validation signals for a security-sensitive concern. The likely path is to vendor/fork the signing logic, add Laravel-native middleware, and own the security review. Pulling it in as an unmodified Composer dependency creates long-term ownership without upstream support.
Technical risk. HMAC authentication is security-critical: canonicalization mistakes, header handling differences, proxy normalization, body encoding, replay windows, clock skew, and key rotation can produce either outages or signature-bypass bugs. An archived package will not receive CVE response, PHP 8.x compatibility fixes, or PSR-7 2.x updates. The 2020 release date raises specific concerns around modern Laravel/Symfony versions, strict PSR-7 return types, and deprecated PHP behavior. The low opportunity score and zero dependents reinforce that this should not become a strategic dependency without a fork-and-own decision.
Key questions.
Stack fit. For inbound Laravel APIs, do not drop this into the global middleware stack. If evaluated, isolate it behind a dedicated route group or a single API surface, bridge Illuminate\Http\Request to PSR-7, and preserve the raw body before Laravel’s request parsing. For outbound signing, evaluate it inside the Guzzle handler stack used by Laravel’s HTTP client; that is the cleaner integration point. Avoid mixing both inbound and outbound signing in the same first release.
Migration path. Treat the package as a reference implementation, not a permanent dependency. Sequence: extract the signing/canonicalization behavior, write Laravel-native middleware or a small signer service, pin a forked version only if the code is clean and tested, then replace it with internal code or a maintained alternative. If a quick POC is needed, vendor the package and document the fork point. Do not expose it as a shared platform dependency until the wire contract and security properties are validated.
Compatibility. Verify Composer constraints against the target Laravel/PHP matrix before committing. Specifically check PHP 8.1/8.2/8.3 compatibility, PSR-7 1.x vs 2.x return types, Symfony PSR-7 bridge versions, and Guzzle versions used by Laravel’s HTTP client. The archived 2020 release may install but still fail at runtime due to interface changes or deprecations. Test raw-body handling, duplicate headers, query-string ordering, and proxy header behavior in the actual deployment topology.
Sequencing. First, confirm the security requirements and exact HMAC wire format. Second, run a two-day POC against one internal API or one outbound integration. Third, complete a security review of canonicalization, replay protection, and secret handling. Fourth, fork or implement natively with contract tests and fixed test vectors. Fifth, roll out behind a feature flag with dual-auth support, then remove the legacy path after observability confirms stable signature verification.
Maintenance. Adoption means owning the code. The package is archived, so dependency upgrades, PHP compatibility, PSR interface changes, and security patches become internal work. MIT licensing makes a fork possible, but the fork still needs an owner, release process, and vulnerability response path. For a TPM, this is a “build/own” decision disguised as a package adoption.
Support. There is no upstream support channel and no active maintainer response. Internal teams will need runbooks for signature failures, key rotation, clock skew, and replay-store outages. Support burden is highest during onboarding of external partners because HMAC canonicalization mismatches are difficult to debug without good logging and test vectors.
Scaling. HMAC computation itself is cheap and scales horizontally. The operational scaling concern is replay protection: a nonce store typically means Redis or another shared low-latency store, plus key lookup/caching. Multi-tenant secrets and key rotation add configuration and cache-invalidation complexity. Signature verification should not become a per-request database lookup.
Failure modes. Expect failures from clock skew, mismatched canonicalization, proxy-altered headers, body encoding differences, duplicate headers, rotated or mis-scoped secrets, and replay-cache outages. Security failure modes include weak secret storage, missing replay checks, overly broad clock tolerance, and inconsistent verification between environments. Instrument signature failures with client ID, route, timestamp skew, and reason codes—never log secrets or full signatures.
Ramp-up. Teams need HMAC fundamentals, PSR-7 bridging knowledge, and Laravel middleware ordering awareness. Budget for documentation, fixed test vectors, partner onboarding guides, and a security review. Given the archived status and zero dependents, the recommended TPM position is: use only as a short-term reference or forked component, not as a long-term platform dependency.
How can I help you explore Laravel packages today?