Laravel Bastion Laravel Package

Product Decisions This Supports

• Build vs. buy for API-key auth: Bastion is a narrow accelerator, not a platform bet. It supplies the table-stakes primitives — hashed token issuance, scoped access, revocation, and test/live credential isolation — that would otherwise cost an engineering team weeks to build and harden. MIT licensing and a small codebase keep switching costs low; that lowers the decision's stakes but does not remove the need for a security read.
• Roadmap sequencing: Treat API-key authentication as an enabling capability that sits before partner integrations, a developer sandbox, machine-to-machine credentials, CLI/automation tokens, rate limiting, API analytics, usage-based billing, and a developer portal. Those features assume an identity-and-scope model already exists; building them on top of an unresolved auth decision creates rework.
• Feature scoping / boundary setting: Adopt it for credentials issued to organizations, services, and integrations — per-integration keys with narrow scopes — and explicitly not for end-user login, social sign-on, SSO, or delegated authorization. Writing that boundary down prevents a second, divergent auth system from creeping in alongside Sanctum or Passport.
• Time-to-market bet: For an MVP, internal API, or partner API, the value is speed to a credible credential story. For a regulated or high-assurance product, the package's value is as a requirements template: the gap analysis (rotation with overlap, audit logging, tenancy, expiry policy) becomes the specification for a custom or commercial build.
• Decision guardrail: Fund one time-boxed spike with explicit pass/fail criteria — scope enforcement, environment isolation under adversarial testing, key lifecycle, coexistence with existing guards. Decide from evidence, not from the README.
• A due-diligence item the sources surface themselves: The repository positioning ("Stripe-inspired API authentication with environment isolation, granular scopes") and the packaged description (an invitation/onboarding system) describe two different products. Confirm which capability the released code actually delivers before it appears in any roadmap, estimate, or customer commitment.

When to Consider This Package

• Consider it when the product is Laravel/PHP, needs long-lived bearer credentials for external consumers or internal services, and requires per-key scopes plus a hard separation between test and production keys.
• Consider it when the alternative is hand-rolling token generation, hashing, prefix-indexed lookup, and scope checks — and the team can accept a community-maintained, MIT-licensed dependency with a fork as a realistic fallback.
• Consider it when scope is bounded: an MVP, an internal API, or a partner API where a competent Laravel engineer can complete a working spike in under a day and a security read of the source shortly after.
• Look elsewhere when requirements include OAuth2/OIDC/SAML, enterprise SSO, refresh flows, delegated third-party access, or relationship-based authorization. Sanctum is the better fit for first-party SPA and mobile sessions; Passport for full OAuth2.
• Look elsewhere when the product needs commercial support, an SLA, a security audit trail, or a multi-year maintenance record. The ecosystem signals are thin — roughly 109 stars, zero dependents, a single maintainer, release 0.0.2 — which is a statement about validation rather than code quality, but it shifts risk onto your team.
• Look elsewhere if its data model conflicts with existing user/tenant structures, it cannot coexist cleanly with current auth guards, or migration and exit costs are high enough that a small dependency becomes a large commitment.
• Before production, verify at the code level rather than from docs: keys stored hashed with prefix-indexed or constant-time lookup; environment isolation enforced in the guard rather than advisory; scopes actually gating the middleware; rotation with an overlap window rather than only hard revocation; and a supported Laravel/PHP version matrix with tests covering the security-critical paths.

How to Pitch It (Stakeholders)

• For executives: Bastion is a small, MIT-licensed Laravel package that can shorten the path to an API product by supplying Stripe-style authentication — environment-isolated keys, granular scopes, revocation — at essentially zero license cost. The risk is concentrated in maturity and support, not price. The recommendation is a short, criteria-driven pilot with a clear exit, not org-wide adoption and not a public commitment until the pilot closes. If it passes, we ship faster; if it fails, the requirements carry straight into a custom or commercial build.
• For engineering: Evaluate it as a foundation for machine-to-machine and partner API keys, explicitly not as a replacement for OAuth or user identity. Wrap it behind an internal auth interface so the implementation stays swappable, pin the version, and expect to own the surrounding policy work the package does not provide: issuance and rotation workflow, scope taxonomy, audit logging, and a revocation runbook. Assume the code is small enough to vendor or fork in a day.
• What we are asking for: Approval of a time-boxed spike testing scopes, test/live isolation under adversarial conditions, key lifecycle, and coexistence with existing guards — plus resolution of the documentation inconsistency between the repository description and the packaged docs before anything reaches a customer. The ask is cheap and reversible, and it produces a decision grounded in evidence.