Laravel Licensing Client Laravel Package

Product Decisions This Supports

• Build vs. buy on licensing/entitlement enforcement. This package offloads the mechanics of license issuance verification and entitlement gating (PASETO tokens, Ed25519 signatures, claim validation) to a maintained dependency paired with laravel-licensing server v2.0.0, letting the team invest engineering time in product features rather than cryptographic plumbing.
• Offline and on-prem/air-gapped deployment strategy. Certificate chain verification with public key bundle application and validator initialization from a stored bundle on boot means a customer instance can validate licenses and survive key rotation without calling home on every request. This unlocks on-prem and regulated-environment segments that were previously hard to serve.
• Packaging and monetization roadmap. First-class entitlements storage/retrieval plus exposed claims (entitlements, licensable_type, licensable_id) give a clean substrate for tiered plans, seat/feature gating, and per-tenant licensing, without bespoke schema work per product line.
• Security and compliance posture decisions. Issuer (iss) validation, not-before (nbf) validation, and configurable ±60s clock skew bring token handling in line with standard JWT/PASETO practice — a prerequisite for security review sign-off in enterprise deals.
• Platform support commitments. Explicit PHP 8.4/8.5 and Laravel 13 coverage informs the upgrade calendar and lets us commit to a modern runtime baseline without carrying an unsupported dependency.
• Upgrade sequencing. The v1.0.0 → v2.0.0 breaking changes (issuer enforcement, certificate chain verification) are a hard gate tied to the server v2.0.0 rollout and must be scheduled as a coordinated client/server migration, not an incidental patch.

When to Consider This Package

Adopt when all or most of the following hold:

• The product is a Laravel/PHP application that needs to enforce commercial licenses or feature entitlements at runtime.
• There is (or will be) a laravel-licensing server v2.0.0 counterpart; v2.0.0 client is explicitly built for it, and the issuer breaking change requires it to be configured consistently.
• Offline verification matters — on-prem, air-gapped, edge, or high-latency deployments where per-request license callouts are unacceptable.
• Cryptographic rigor is a sales requirement — signed tokens, chain-of-trust key rotation, and standardized claim validation are being asked about in security questionnaires.
• The team wants entitlements as a first-class concept rather than string-matching license keys scattered across the codebase.
• You can absorb a coordinated breaking upgrade: setting licensing-client.issuer, ensuring tokens carry a valid issuer, and confirming any footer certificate chains validate against the root public key.

Look elsewhere when:

• Billing and entitlement logic is already fully owned by a SaaS platform (Stripe, Paddle, Chargebee) and no self-issued license tokens exist — adding a second licensing authority creates two sources of truth.
• You need usage metering, seat-count reconciliation, or true-up reporting; this package validates and exposes entitlements but does not appear to be a metering or billing system.
• The stack is not PHP/Laravel, or licensing is needed in mobile/desktop clients where a different SDK is required.
• You require online, real-time revocation with sub-minute propagation — offline-capable token validation is fundamentally a cached-trust model, and short token lifetimes plus re-issuance become the mitigation, not instant revocation.
• You cannot take a breaking-change upgrade in the current cycle; staying on v1.0.0 is viable only while the server remains on v1.x, which is a shrinking window.

How to Pitch It (Stakeholders)

For executives: This release turns license enforcement from a custom-built liability into a supported, security-reviewed component. Ed25519 certificate chain verification and offline key rotation let us sell into on-prem and air-gapped accounts we currently can't serve, and first-class entitlements give us a clean lever for tiered pricing. The cost is a deliberate, scheduled upgrade — v2.0.0 rejects tokens with a mismatched issuer and now verifies footer certificate chains — so it should be planned alongside the server v2.0.0 rollout, not slipped in as routine maintenance.

For engineering: v2.0.0 is a substantive but well-scoped upgrade. Wins: PASETO issuer and nbf validation with configurable ±60s clock skew (fixes a real class of edge-case auth failures), public key bundle application and boot-time validator initialization for offline operation, entitlements API, and expanded claim surface. Watch items: two hard breaking changes — licensing-client.issuer must be configured to match the server or all tokens are rejected, and tokens carrying a certificate chain in the footer are now verified against the root public key, which will surface any malformed chains in existing test fixtures. Mitigations are straightforward: pin the config in every environment including CI, add a migration test with a v2.0.0-issued token, and validate the rotation path before rollout. PHP 8.4/8.5 and Laravel 13 are now in the test matrix, so the dependency won't block our runtime upgrade.