strobotti/php-jwk
A lightweight PHP library for JSON Web Keys (JWK/JWKS). Parse, validate, and generate RSA and EC keys, build key sets, and integrate with JWT signing and encryption workflows. Framework-agnostic, Composer-ready, and useful for securely managing public/private keys in PHP applications.
Architecture fit. strobotti/php-jwk is a narrow, single-purpose utility: it models JSON Web Keys and Key Sets and converts them into forms PHP's crypto layer can consume (PEM/DER export, OpenSSL keys, base64url helpers). That narrowness is the point. In a Laravel codebase it belongs in the infrastructure layer behind one or two small adapter classes — an JwkKeyFactory/JwksResolver service bound in the container — not sprinkled through controllers or middleware. It complements rather than replaces a JWT library: firebase/php-jwt or lcobucci/jwt handles token parsing and signature verification, while this package handles the key material on either side of that call (loading a JWKS document, selecting a kid, converting a JWK to a PEM or OpenSSL key for verification, or emitting a public JWK from your own signing key). If your requirement is simply "verify a JWT with a shared secret" you do not need this package at all. Architecture fit is strong specifically for multi-issuer OIDC, JWKS rotation, and "bring your own key material" scenarios.
Integration feasibility. Low-to-moderate effort. It is a Composer library with no Laravel service provider, no config, no facade — which is normal and actually preferable, since wrapping it yourself gives you a seam for testing and for swapping it out. Expect a half-day to a day to spike: install, wrap, load a JWKS fixture, verify an RS256 token end-to-end, then repeat for ES256 if you need it. The real work is not the library call, it is building the surrounding policy: JWKS caching and refresh, kid resolution and misses, algorithm allow-listing, and rejecting none/HMAC-confusion inputs. Budget for those explicitly; they are the actual deliverable.
Technical risk. The dominant risk is supply chain and longevity, not correctness. The metadata available to us is thin and partly inconsistent: the repository field is "unknown," there is no linked source location in this record, adoption is very low (25 stars), and the "last release 2026-07-03" timestamp is either a data-quality artifact or a forward-dated tag — either way it means we cannot currently confirm the project's release hygiene or maintenance cadence from this record alone. That combination — tiny user base, single effective maintainer, unverified provenance — is what a security review will push back on. Mitigating factors: MIT license, small surface area, and the fact that it is a thin wrapper over openssl_* and json_decode, so the worst-case exit is a few hundred lines of replacement code written in-house. This is a "low blast radius, non-trivial provenance risk" package — acceptable as a disposable dependency, questionable as a load-bearing one. Secondary risk: JWK/JOSE is a spec with sharp edges (base64url without padding, EC coordinate padding, use/key_ops/alg constraints, x5c chains). Verify the package enforces or at least surfaces these, and do not assume it does.
Key questions. What is the canonical repository URL, and does it match the Composer package name and the tagged releases? Who has commit and packagist release rights? Is there a CI matrix, and which PHP versions are actually tested? Which key types are supported — RSA only, or EC/P-256 and OKP/Ed25519 as well? Does it validate alg against the key type, or will it happily hand you a key for an algorithm you did not intend? Does KeySet expose kid lookup and handle duplicate/missing kid deterministically? Does it reject private parameters in a JWKS fetched from a third party? What is the stated support window and does the maintainer respond to issues and security reports? Do we have a documented fallback if the package is abandoned?
Stack fit. Clean fit for Laravel 9–11 on PHP 8.1+. It is framework-agnostic, so it drops in without touching config/app.php or the service container beyond a single binding. It has no queue, cache, or filesystem opinions, which means the operational decisions — where the JWKS cache lives, TTLs, negative caching — stay yours. That is the right split: the library should not be making caching decisions for you. Constrain it to a App\Support\Jose namespace with an interface in front (KeyResolver::resolve(string $kid, string $alg): Key) so that application code never type-hints a vendor class. That single rule is what makes the vendor-risk conversation go away.
Migration path. Two directions. Inbound: if you are currently hardcoding a PEM in .env or a config file for a single identity provider, introducing this package is the first step toward supporting a JWKS endpoint and key rotation; the migration is additive — keep the static PEM path as a fallback resolver behind the same interface while the JWKS resolver is validated in staging. Outbound: if you already use firebase/php-jwt, you can adopt this package purely for key conversion and leave token handling untouched, which is the lowest-risk first slice. If the package is later abandoned, the exit is to reimplement Key::toPem()/KeyFactory::createFromJson() over openssl_pkey_get_details — bounded, testable work.
Compatibility. Check PHP version support against your floor and against your other JOSE dependencies to avoid a conflict on paragonie/constant_time_encoding or similar. Confirm behavior under both OpenSSL 1.1.1 and 3.x if you run a mixed fleet, since EC handling and key serialization differ. Verify that the private-key export path used for signing produces output your JWT library accepts without a round-trip through the filesystem (avoid temp files — pass PEM strings directly). On the Laravel side, ensure the package does not conflict with lcobucci/jwt's own key abstractions if both are present; prefer one JOSE key model per service.
Sequencing.
composer audit, license scan, and a decision on whether the dependency is acceptable as "disposable." Record the decision and the exit plan.KeyResolver implementation with kid-miss handling, alg allow-list, and cached JWKS with explicit TTL and stale-on-error policy. Contract tests against a local JWKS server./jwks.json endpoint).Maintenance. Near-zero code maintenance — the API is small and stable, and JOSE's key formats are not moving. The maintenance burden you own is the policy layer around it: JWKS fetch/refresh, cache invalidation on rotation, algorithm allow-listing, clock skew on token validation. Budget ongoing attention there, not in the library. Dependency management is a composer update line item; a 25-star package is unlikely to be a frequent source of churn, which cuts both ways (few updates, few fixes).
Support. This is the weak point. With a single-maintainer, low-adoption project you should assume no SLA and no timely security response. Do not put it on a path where a CVE in it blocks a release. Practically: pin a version, keep the wrapper interface, and pre-write the replacement (it is small). If your organization has a policy requiring maintained dependencies for anything touching authentication, this package will need an explicit exception with a named owner and a review date — get that in writing before the first commit, not after.
Scaling. Effectively irrelevant at the application tier — key parsing is microseconds and happens per-request or per-cache-miss, not in a hot loop, and results should be cached in the resolver anyway. The scaling concern is upstream: if you fetch JWKS from an identity provider on every request you will hammer them and add latency and a hard dependency on their availability. Cache the parsed key set in Laravel's cache with a TTL aligned to the provider's rotation cadence, serve stale on fetch failure, and rate-limit refreshes. That is your code, not the library's.
Failure modes. (a) Unknown kid — either rotation lag or an attacker probing; must produce a controlled 401, not an exception bubbling to a 500, and must not fall back to "try every key." (b) Malformed or partially-specified JWK — missing alg/use, unpadded EC coordinates; decide fail-closed. (c) Algorithm confusion — the library will not stop you from verifying an RS256 token with a key the attacker chose; your resolver must bind alg to key type. (d) Abandonment — no upstream fix for a future bug; mitigated by the wrapper and a small, pre-scoped replacement. (e) Supply chain — unverified repository provenance means a compromised release is plausible; mitigate with version pinning, composer.lock review, and an internal mirror if policy requires it. (f) Cache poisoning of JWKS — validate TLS, pin the issuer URL, and never accept a JWKS from a user-supplied URL.
Ramp-up. A competent PHP engineer unfamiliar with JOSE needs roughly a day with RFC 7517/7518 open alongside the code to be productive here; the library's small surface helps, but the spec's sharp edges are the actual learning curve. A Laravel engineer who already knows firebase/php-jwt will pick it up in an hour. Recommend one owner, a short internal note covering the wrapper interface, the caching policy, and the failure-mode table, plus fixture-based tests so the next person can verify behavior without re-reading the RFCs. Total onboarding cost is small; the institutional knowledge that matters is the policy, not the package.
How can I help you explore Laravel packages today?