juststeveking/http-auth-strategies
A Laravel package offering reusable authentication strategy classes for HTTP requests, letting you encapsulate and swap Basic, Bearer, and custom auth schemes cleanly instead of scattering credentials through your code.
Architecture fit. The package occupies a narrow, defensible seam: composing Authorization and custom headers on outbound HTTP requests. From a TPM perspective this is the correct place for an abstraction — a named strategy resolved through Laravel's container and selected per integration is structurally better than header assembly scattered across controllers, jobs, and console commands, because it gives you one auditable place to answer "what exactly do we send to vendor X, and with which secret?" The v1.2.0 CustomStrategy is the commercially interesting part: Basic and Bearer are already one-liners on Laravel's Http facade (withToken(), withBasicAuth()), so the package's differentiated value is the long tail — X-API-Key providers, tenant/routing headers, dated HMAC-style signatures, legacy key auth. Value therefore scales with integration count and heterogeneity, not company size. A single-integration shop gets nothing here.
Scope discrepancy — resolve before scoping. The supplied documentation is internally inconsistent and this materially changes the effort estimate and the security review. The package description frames it as reading and normalising inbound Authorization headers; the product assessment frames it as composing outbound headers. These are different packages, different threat models, and different reviewers. A TPM should treat "confirm inbound vs. outbound vs. both" as gate zero — before the spike, before the estimate, before anyone writes an ADR. If someone assumes inbound and it is outbound (or vice versa), the work is mis-scoped by an entire review cycle.
Integration feasibility. Low effort on the happy path: Composer install, a config block per integration, at most a small class implementing the strategy contract. No migrations, no queue changes, no impact on end-user login. Realistic scoping is hours of engineering plus a security review, with a ~1–2 day in-house fallback if we walk. That estimate is conditional on the package running on our stack, which the available evidence does not establish — the release note is one changelog line and says nothing about the supported PHP/Laravel matrix.
Technical risk. Blast radius is contained and reversible; the dependency-level risk is materially larger than the feature-level risk, and a TPM should separate the two:
CustomStrategy, and whether the package wraps Guzzle or Http (thereby pinning a client major) are all unverified.Key questions for the spike. Does CustomStrategy accept arbitrary header names, and are they validated? Can values be sourced from env or a secret manager rather than committed config? What is the resolution order against existing strategies, and is it logged? Which PHP and Laravel versions are supported, and does that intersect our matrix? Is there CI, and does it exercise the new strategy? And critically: confirm this is outbound authentication only — composing headers toward third parties is an entirely different security review from inbound end-user identity.
Stack fit. A Composer-installed Laravel package living in the outbound HTTP layer. It fits anywhere the application calls authenticated third-party or internal APIs and currently repeats header construction. It is explicitly not a fit for end-user login, session handling, or token issuance — record that boundary in the ADR so nobody later "consolidates" inbound identity into this abstraction.
Migration path. Pin an exact version; never float a constraint or track dev-main on credential-handling code. Frame this as adoption on the next integration, not a migration project. If the team already carries a fork, a subclass, or a hand-rolled header handler, deleting that in favor of CustomStrategy is the migration — and its value should be reported in bespoke auth code removed, not features gained.
Compatibility. Three checks, in order: (1) package PHP/Laravel constraints against our current matrix — given the 2020 release date this is the most likely blocker and should be checked first, before any design work; (2) whether the strategy contract gained methods our in-house implementations would have to satisfy; (3) HTTP client coupling if the package wraps Guzzle or Http. Record the outcome in the repo, not a chat thread, so the next integrator doesn't re-litigate it.
Sequencing. Spike on a branch → write one test asserting the exact outbound header set for one real integration (this single artifact catches nearly every downstream regression) → ship to one low-risk internal service → then external vendors → then payments or identity last, never first. Run header-validation review concurrently with the spike, not after rollout. If the spike fails on PHP/Laravel constraints, stop and take the in-house fallback — carrying no supply-chain exposure is a perfectly good outcome at ~1–2 days.
Decision criteria to publish. Adopt the pattern if three or more roadmap integrations need non-standard headers; if only one or two, use withToken()/withBasicAuth() and skip the dependency entirely. If compliance or security review gates third-party code touching credentials, the activity signals are likely disqualifying on their own.
Stakeholder framing. For executives: the capability turns per-integration auth plumbing into configuration, cutting effort and duplicated credential handling as vendors are added; the library itself is low-activity and unreleased since 2020, so the recommendation is to adopt the pattern — a single internal auth-strategy seam, optionally seeded from this package's design — rather than take on dependency risk in credential-handling code. Cost is measured in hours, the change is additive and reversible. For engineering leadership: what it removes is the "we can't standardize because vendor X needs a weird header" objection; what it does not solve is token lifecycle, refresh, secret storage, retry policy, observability, or inbound login.
Maintenance. Ongoing feature cost is low because the surface is small; the carrying cost is the dependency itself. With no dependents and no release since 2020, plan for eventual ownership — budget a vendoring or fork-if-necessary contingency before this touches a business-critical path. The other accumulating cost is configuration sprawl: one bespoke strategy per vendor becomes unauditable fast. Impose a convention before the second integration, not the fifth — one config block per integration, secrets from the secret manager, never literals in committed config.
Support. Expect tickets that look like auth failures but aren't: X-API-Key vs X-Api-Key, a trailing newline in a rotated secret, a header a proxy strips, a stale token, a strategy silently not applied. The highest-leverage investment is debug-level logging of the resolved strategy name and header names per integration — never values — so on-call can distinguish "wrong strategy selected" from "vendor rejected our credential" without reading source. Without that, every vendor 401 becomes an engineering investigation.
Scaling. Scales linearly and benignly with integration count, which is the point — the marginal cost of vendor N+1 drops to a config block plus a header assertion test. What does not scale is governance: the abstraction only holds if secret retrieval, rotation, and audit stay centralized. Decide early whether the strategy lives app-level or in a shared internal package; that is a platform-team call with a visible cost curve, and it gets expensive to reverse once five services have copied it.
Failure modes. Ranked by likelihood and cost: (1) a silently mis-resolved strategy sending the wrong credential to the wrong host — the worst case, mitigated by deterministic precedence plus logging; (2) PHP/Laravel drift after a framework upgrade, with no maintainer to patch it — mitigated by exact version pinning and a vendoring plan; (3) a breaking change in the strategy interface if we ever float the constraint — mitigated by never floating it; (4) header injection via config-sourced values — mitigated by RFC 7230 validation in review; (5) abandonment, leaving the team as de facto maintainers of credential code.
Ramp-up. Low for any Laravel developer — one config file and a named strategy is an afternoon's work, and the pattern is legible to new hires. The ramp-up cost is not learning the package; it is learning the convention (where strategies are registered, where secrets come from, how to add a header assertion test). Write that down as a short internal runbook on first adoption. Success metric: integrations onboarded via configuration only — zero bespoke auth code — plus a measurable reduction in duplicated header logic across the codebase.
Recommendation. Borrow the pattern; don't bet the supply chain on it. Confirm inbound vs. outbound first, adopt the abstraction on the next integration with an exact version pin, keep the implementation in-house and replaceable, and ensure credentials never depend on a package last touched in 2020.
How can I help you explore Laravel packages today?