Product Decisions This Supports
- Authentication strategy for service-to-service and signed-request traffic. Hawk (MAC-based HTTP authentication, originally from the Mozilla/Firefox Accounts ecosystem) is a candidate whenever we need per-request integrity and replay protection rather than bearer tokens. This package is the reference point for "what does a server-side Hawk verifier actually have to do": credential lookup by key ID, timestamp window checks with clock-skew tolerance, nonce storage to block replay, optional payload hash verification, and
bewit (pre-signed URL) support.
- Build vs. buy vs. borrow. With zero stars, zero dependents, and a score of 0, this is not a "buy." The realistic decision this package informs is borrow the design, build the verifier: a Hawk server verifier is a bounded, well-specified surface (a few hundred lines plus a nonce cache), which is often cheaper than adopting an unvetted dependency.
- Framework-fit triage. The package is a Symfony bundle, not a Laravel package — it ships a
Bundle class, DI extension, and Symfony security-firewall integration. On a Laravel codebase that means no service provider, no middleware, no config publishing; adopting it implies writing an adapter layer or a thin reimplementation. This is a scope signal for roadmap sizing, not a feature.
- Interop-driven roadmap items. If we must talk to a counterparty that already speaks Hawk (legacy Mozilla-lineage APIs, pre-signed download links via
bewit), this defines the minimum viable compatibility set and the conformance tests we'd need.
- Operational dependency scoping. Nonce/replay protection requires a shared, low-latency store (Redis/Memcached) with TTLs aligned to the timestamp window. That's an infrastructure ask that belongs in the same planning cycle as the auth work, not after.
- Risk/tech-debt register entry. Undeclared star count, no dependents, no visible maintenance signal → supply-chain and bus-factor risk. Useful as a documented "considered and rejected" so the choice isn't relitigated each quarter.
When to Consider This Package
Consider it (as a reference implementation or a fork candidate, not a drop-in) when:
- You are on Symfony and need Hawk server-side verification, and you're prepared to vendor/fork and own the code.
- You have a hard interop requirement: an existing client or partner service already sends
Authorization: Hawk ... headers or ?bewit= URLs, and rewriting both sides is off the table.
- Your threat model needs per-request MAC + replay protection + optional body-hash integrity, and bearer tokens (Sanctum/Passport) or plain mTLS are insufficient or operationally awkward.
- You want a compact, readable spec-shaped implementation to validate your own design against — the bundle's structure (credential provider, nonce validator, header parsing) is a useful checklist even if you never install it.
Look elsewhere — or write it yourself — when:
- You're on Laravel. Use
laravel/sanctum for first-party SPA/token auth, laravel/passport (OAuth2) for third-party delegated access, or web-token/jwt-framework / firebase/php-jwt for signed tokens. For request signing, an HMAC-middleware plus a league/ or first-party signer is less friction than adapting a Symfony bundle.
- Any maintenance or compliance bar applies. Zero dependents and no activity means no CVE response, no PHP 8.x/Symfony 6–7 compatibility guarantees, and no community answer to "why does it fail behind a proxy?" Your security review will (correctly) reject it as a direct dependency.
- A better-fitting standard exists. AWS SigV4-style signing, OAuth2 with DPoP/mTLS-bound tokens, or JWT with short TTLs cover most of the same ground with mainstream tooling, libraries, and auditors who've seen them before.
- You need rich authorization. Hawk authenticates and protects the request; it does not model scopes, roles, or consent. Pairing it with an authorization layer is unavoidable — budget for that.
- You need vendor support. Nothing here offers SLAs, docs beyond the README, or a release cadence.
Mitigations if you do proceed: fork and pin to a commit, add it to the internal maintainer list, wrap it behind our own HawkVerifier interface so it's swappable, and write conformance tests against the spec vectors before any production traffic.
How to Pitch It (Stakeholders)
Executive summary: This is a small, unmaintained Symfony bundle implementing the server half of Hawk, an HTTP request-signing scheme from the Mozilla ecosystem. It has no visible adoption — zero dependents, no stars — so I do not recommend it as a dependency. I do recommend it as a design reference if we pursue signed-request authentication.
Engineering: It tells us the shape of the problem — credential lookup, timestamp window, nonce/replay cache, payload hash, bewit URLs — and it's small enough that a clean implementation behind our own interface is roughly a sprint, on either Laravel or Symfony. It is not installable on Laravel without an adapter; treat any "just add the bundle" estimate as wrong. It also commits us to a Redis-backed nonce store.
Decision framing for the roadmap: The real question isn't "this package or not" — it's "do we need per-request signing at all?" If the answer is yes because a partner already speaks Hawk, we build a minimal verifier and own it (~1 sprint + infra). If the answer is no, we standardize on Sanctum/Passport for first-party and OAuth2 for third-party, and we close this out with a documented rationale. Either way, we spend little and de-risk the auth surface rather than inheriting an unvetted dependency.