Technical Evaluation

Architecture fit

ReallySimpleJWT is a framework-agnostic, dependency-light JWT (JWS) library with a small static surface — create, validate, validateExpiration, getPayload, getIssuer — signing with HMAC secrets. It is not a Laravel auth driver: there is no service provider, no guard, no middleware, no config publishing, no user/refresh-token model, and no revocation store.
Realistic fit in a Laravel estate: internal service-to-service tokens, signed webhook payloads, short-lived capability tokens (magic links, download grants), and lightweight stateless auth between first-party services. Poor fit as the primary user-session mechanism where Sanctum/Passport or tymon/jwt-auth already provide guards, token persistence, and refresh flows.
Its static API is the main architectural friction: calling Token::create() directly inside controllers makes tests and secret-rotation logic hard to control. A thin injectable adapter interface bound in a service provider is effectively mandatory.

Integration feasibility

composer require rbdwllr/reallysimplejwt and go. No PHP extensions beyond hash/json, no database, no network calls.
Total integration work is small: config entry (secret, TTL, issuer), an adapter class, one service-provider binding, exception-to-401 mapping. Roughly 1–2 engineer-days including tests for a team already comfortable with Laravel.
Main feasibility question is not "can we" but "should we own it": a 288-star, single-maintainer library with no release since April 2022 and effectively no dependents means near-zero ecosystem pressure to keep it current.

Technical risk

Maintenance risk is the dominant risk: no releases in ~3 years, single maintainer, low adoption signal (0 listed dependents). Newer PHP runtimes (8.3/8.4) may surface deprecations that will never be patched upstream.
Capability gaps to verify in a spike: algorithm coverage (HMAC only in mainstream usage vs. need for RS256/ES256), no JWKS/OIDC discovery, no kid-based key rotation, limited claim validation (exp/nbf/issuer; audience handling is minimal), no encryption (JWS only), no token revocation, no clock-skew/leeway configuration, no framework middleware.
Security surface is small and auditable (a positive), but the library enforces a minimum HMAC secret length and throws exceptions rather than returning booleans in some paths — every call site must catch and normalize errors, or 500s leak.

Key questions

Do we need asymmetric signing (RS256/ES256) so third parties can verify without holding our secret? If yes, this library is likely disqualified.
Is token revocation, refresh, or long-lived session state required? If yes, pair with a denylist or choose Sanctum instead.
What is our policy on unmaintained dependencies — fork-and-own, vendor, or reject?
Who owns CVE triage for a dormant package, and what is the response SLA?
Can we commit to an adapter layer so the library is swappable for firebase/php-jwt or lcobucci/jwt later?
What is our secret-rotation story without kid support?

Integration Approach

Stack fit

Laravel 9–11, PHP 8.1+ (confirm the package's constraint in CI before committing). No provider required; add one only for the adapter binding.
Secret handling: store in config/services.php or config/jwt.php reading env('JWT_SECRET'), never env() at call sites — config:cache will silently return null otherwise. Consider deriving from a secrets manager at boot for non-local environments.
Octane-safe: the library is stateless, but confirm no static mutable state before enabling under Octane workers.

Migration path

Introduce the adapter interface before choosing the implementation, so the package is an implementation detail from day one.
If replacing an existing JWT library: dual-issue during transition, validate both token shapes by inspecting the header/issuer, gate new issuance behind a feature flag, then sunset the old issuer after the maximum token TTL has elapsed.

Compatibility

Check the transitive dependency footprint is genuinely zero (as advertised) and that it does not pin psr/* versions that conflict with Laravel's HTTP stack.
Run the full test suite on the highest PHP version in the CI matrix; deprecation noise is expected and unpatchable. Add a static-analysis baseline so it doesn't drown real issues.
No namespace collision with Sanctum/Passport, so coexistence is fine — you can run both if JWT is scoped to service-to-service only.

Sequencing

Timeboxed spike (1 day): create/validate round-trip, algorithm whitelist behavior, alg: none rejection, malformed-token behavior.
Security read-through of the source (it is small enough to actually read) plus a check for known advisories.
Build adapter + config + exception mapping + unit tests.
Ship to a low-blast-radius internal use case (e.g., service-to-service call for one internal API).
Decide explicitly: promote to additional services, or treat as tactical and plan replacement.

Maintenance

Assume you own it. Budget for a pinned version, a periodic review (annual plus on PHP major upgrades), and a documented "fork if broken" decision. Do not expect upstream fixes.
Track it in the dependency register with an owner and a re-evaluation date; flag it as an accepted risk rather than a maintained dependency.

Support

Community-only via GitHub issues on a dormant repo; no commercial backing. Internal runbook is required: how to rotate the secret, how to invalidate tokens, how to diagnose a 401 spike.
Ramp-up is genuinely low — a PHP developer is productive in half a day given the tiny API and clear docs — but the adapter/DI discipline and the exception-to-HTTP mapping add roughly another day.

Scaling

Excellent: HMAC verification is CPU-cheap, fully stateless, no I/O. It will not be a bottleneck at any realistic request volume.
The scaling weakness is organizational, not technical: with no kid header support, rotating the signing secret requires coordinated rollout and a dual-secret acceptance window in the adapter (accept old and new, issue with new) to avoid mass 401s.

Failure modes

Clock skew between services causes spurious exp/nbf failures — enforce NTP and consider a small leeway implemented in the adapter.
Secret rotation without a dual-accept window invalidates every outstanding token simultaneously.
Uncaught library exceptions surface as 500s instead of 401s; every validation path must be wrapped.
config:cache with env() called outside config files yields a null/empty secret — signature verification then fails at runtime, usually only in production.
Long-lived tokens with no revocation path mean a leaked token is valid until expiry; keep TTLs short (minutes, not days).
Misconfigured issuer in multi-tenant deployments silently accepts cross-tenant tokens unless issuer validation is enforced on every path.
Algorithm not explicitly pinned at the call site risks algorithm-confusion acceptance; pin HMAC and assert the header.