Api Guard Laravel Package

Product Decisions This Supports

• API monetization / partner-access roadmap: Deciding whether to expose a public or partner-facing API this quarter, and whether API-key auth is the v1 gate before OAuth2 or per-customer JWT. This package models the minimal viable version of that decision: issue key → bind to an entity → validate on request → revoke.
• Build vs. buy vs. borrow: The honest framing is borrow the pattern, not the dependency. api-guard (691 stars, last release Oct 2016, zero dependents) is a well-understood reference implementation of API-key auth — key generation, hashed storage, configurable header/query-parameter lookup, middleware enforcement, and user-bound keys. The PM decision it informs is "what is the smallest correct key-management schema and middleware contract we need," not "should we add this to composer.json."
• Feature scoping against first-party alternatives: Laravel Sanctum now ships token issuance, hashed storage, abilities/scopes, and revocation as a first-party package. This assessment is really a supersession decision: any roadmap item scoped as "add API keys" should be re-scoped as "adopt Sanctum and build the tenant-facing key-management UI on top," which is where the actual product differentiation and 80% of the remaining work lives.
• Data model and lifecycle decisions: Keys attached to users vs. teams vs. service accounts; rotation policy; revocation semantics (soft-revoke and grace period vs. hard delete); whether keys are shown once at creation. These are irreversible-ish schema choices worth locking before build.
• Packaging and pricing decisions: Whether API access tiers are gated by key count, rate limit per key, or scopes. Per-key rate limiting is where commercial tiers usually attach, and it is not something this package solves for you — plan for it explicitly.
• Support-cost and ops decisions: Self-serve key management in the customer dashboard vs. manual issuance by support. The package gives you the backend primitive only; the customer-facing surface is the real cost driver and should be estimated separately.

When to Consider This Package

Consider it when:

• You maintain a legacy Laravel 4.x/5.x application (PHP 5.6–7.x era) that is in maintenance mode, and you need machine-to-machine auth with minimal change surface.
• You need a throwaway prototype or internal POC where the cost of an abandoned dependency is bounded and the app will not ship to production.
• You want a readable reference implementation — the source is small and the schema/middleware pattern is a useful starting sketch for an in-house build or a Sanctum-based design.
• Your team needs a one-afternoon demo of API-key auth to validate a product hypothesis with stakeholders before committing engineering time.

Look elsewhere when:

• You are on Laravel 8+ / PHP 8+. A 2016 release predates the framework's service-provider and middleware contract changes; expect incompatibility and no upgrade path.
• The dependency will be production-critical. Zero dependents plus a nine-year-old last release means no security advisory pipeline, no CVE response, and no community to validate your failure modes. That is a supply-chain risk you cannot mitigate by pinning.
• You need OAuth2, SSO, scoped abilities, token expiry/refresh, or per-key rate limiting — none of which this package addresses at the level a paying customer will expect.
• You have compliance obligations (SOC 2, ISO 27001, customer security questionnaires). An unmaintained auth dependency is a predictable finding in a vendor review; the audit explanation costs more than the build.
• Laravel Sanctum is available — which it is for any modern app. Sanctum is first-party, maintained, and covers hashed token storage, abilities, and revocation. Adopting api-guard alongside Sanctum is strictly redundant.

How to Pitch It (Stakeholders)

To executives: We evaluated api-guard as a shortcut to ship API-key authentication for partner integrations. It is a clean, MIT-licensed pattern, but it was last released in 2016 and has no downstream dependents, which means no security patching and no compatibility with our framework version. Recommendation: do not adopt as a dependency. Reimplement the same pattern on Laravel Sanctum, the maintained first-party equivalent. The delta is roughly a few engineering days for the backend and the real investment in the customer-facing key-management UI — which we would have had to build either way. Net effect: slightly longer to first release, materially lower long-term security and maintenance risk. Note the high opportunity score on this package is a useful market signal: simple API-key auth is still an underserved need in the Laravel ecosystem, which supports building the customer-facing management experience as a differentiator rather than treating keys as plumbing.

To engineering: Treat this repo as a design spec, not a dependency. The parts worth copying: keys stored hashed, never retrievable after creation; lookup via a configurable header with a query-parameter fallback for legacy clients (though we should decide deliberately whether to allow query-param keys at all — they leak into logs and referrers); validation in middleware with a single well-defined 401 contract; keys bound to an owning entity so revocation is a single row update. The parts to rebuild: framework integration, rate limiting, scopes/abilities, rotation with a grace window, and audit logging on create/use/revoke. Sanctum gives us the first four cheaply; the audit log and rotation flow are the genuinely new work.

To security and compliance: We are deliberately declining an unmaintained third-party auth dependency. It has no published advisories, no active maintainer response, and predates current PHP security baselines. The replacement is a first-party package plus an internal design review covering hashing, key display-once semantics, revocation and rotation, and logging hygiene (no keys in request logs). We will document this as a considered decision rather than an omission, which is the answer a customer security questionnaire is actually looking for.