Jose Laravel Package

Product Decisions This Supports

If this package is already in your stack (the more likely PM scenario):

• Technical-debt / dependency-risk triage. The package is archived with no commits since 2018. That makes it a standing item in your security review: any JWT/JWE handling path is authentication-critical, and an unmaintained crypto library means no CVE response, no PHP 8+ compatibility patches, and no upstream fixes. This is a "schedule the migration" decision, not a "keep and monitor" decision.
• Roadmap sequencing for an auth/platform epic. Migrating off it is scoped work — token issuance, token validation, key rotation, and any JWKS endpoint — and it blocks or rides along with PHP runtime upgrades, Laravel major-version upgrades, and any SSO/OIDC work. Put it on the roadmap explicitly rather than letting it surface as an incident.
• Security posture and compliance evidence. If you answer questionnaires about supported cryptography, dependency maintenance, or patch SLAs, an archived crypto dependency is a finding you should disclose and remediate, not discover during an audit.

If you are evaluating it for new work:

• Build vs. buy for token handling. This library covered the full JOSE surface — JWT, JWS, JWE, JWA, JWK/JWKSet — which is genuinely hard to hand-roll correctly. The build-vs-buy answer is still "buy," but buy from a maintained source.
• Feature scope for auth-related roadmap items. It tells you the shape of the requirements your product actually has: signed tokens, encrypted payloads (JWE), key sets with rotation (JWKS), and algorithm negotiation. Use it as a requirements checklist when comparing successors — most lightweight JWT libraries give you JWS/JWT only and stop there.
• Use cases it maps to: stateless API authentication, OAuth2/OIDC client and provider flows, SSO federation, signed/encrypted webhooks, short-lived service-to-service credentials, and multi-tenant key isolation via JWK sets.
• Explicit non-decision: do not adopt for a new build. The same author's successor, web-token/jwt-framework, covers the same capability set and is maintained; lcobucci/jwt and firebase/php-jwt cover the common JWT-only cases. The decision this package should drive is successor selection, not adoption.

When to Consider This Package

Consider it only in these narrow cases:

• A legacy Laravel/PHP application is pinned to an old runtime (roughly PHP 5.5–7.x era) and this library is already integrated and working. Here the question is not "adopt" but "how long can we defer the migration, and what compensating controls cover the gap."
• You need the full JOSE surface — JWE encryption and JWK/JWKSet key management, not just signed JWTs — and you are on an isolated/air-gapped environment where pulling a modern dependency chain is impractical.
• You need a reference implementation to read for algorithm and key-handling behavior while specifying requirements for a replacement.

Look elsewhere when:

• It's new development. Non-negotiable. Archived since 2018 means no security patches; for a library whose entire job is verifying signatures and decrypting tokens, that is a disqualifier.
• You are on PHP 8+ or a current Laravel release. Compatibility and deprecation risk is high and nobody upstream is fixing it.
• You need modern algorithm support — EdDSA/Ed25519, current EC curves, or algorithm policy that reflects post-2018 guidance — or you need to reject weak algorithms defensively.
• You need an actively maintained dependency with a CVE response process, or you have any procurement/security review that asks about dependency maintenance status.
• You want framework-native ergonomics. Laravel-first wrappers (e.g. tymon/jwt-auth) or the maintained successor with its Symfony bundle will cost less integration effort than retrofitting an archived library.

Practical successor note: because the successor shares authorship and conceptual model, migration is mostly namespace and API mapping rather than redesign. Budget it as a contained epic, not a rewrite — but do verify the JWE/JWK paths you actually use, since that is where API drift concentrates.

How to Pitch It (Stakeholders)

To executives — one paragraph: We have a cryptography library in our authentication path that has been archived and unmaintained since 2018. The license is permissive and there is no commercial cost or vendor lock-in, but the risk is real: if a vulnerability is found in how we verify tokens, no one is going to publish a fix. This is not a fire, but it is a known, bounded piece of technical debt that will eventually block our PHP and framework upgrades and will show up in security reviews. I'm recommending we fund a scoped migration to a maintained library with the same capabilities, scheduled alongside the next platform upgrade rather than as an emergency.

To engineering — the ask: Inventory every usage of spomky-labs/jose (issuance, validation, JWKS endpoints, JWE paths). Map each to the successor's API. Write characterization tests against current token behavior before swapping so we can prove byte-level compatibility on tokens already in the wild. Plan a dual-read window so previously issued tokens keep validating. Flag any JWE or custom key-resolution logic as the high-risk surface.

Framing that lands with both: this is a cheap fix now and an expensive one during an incident. The capability set is not in question — full JOSE support was the right requirement when it was chosen, and it remains the right requirement. The change is purely about who is maintaining it.