- What is jdr/jws-ecdsa used for?
- jdr/jws-ecdsa is a PHP package for signing and verifying compact JSON Web Signature tokens with ECDSA keys. It provides ES256, ES384, and ES512 signer implementations that plug into lcobucci/jwt's Signer abstraction, so it fits token issuance and validation in Laravel or plain PHP. It is a narrow adapter for ECDSA signing, not a full authentication or key-management platform.
- How do I install jdr/jws-ecdsa in Laravel?
- Install it with Composer as a dependency in your Laravel application. There is no service provider or package config file to publish, so you wire the signer and key into your own container bindings, auth guard, or middleware. In practice the integration effort is small; the larger work is managing EC keys, rotation, and public-key distribution.
- Does jdr/jws-ecdsa support ES256, ES384, and ES512?
- Yes. It targets the common P-256, P-384, and P-521 curves with the matching ES256, ES384, and ES512 JWS algorithms. The curve and hash must be paired correctly, for example ES256 with P-256 and SHA-256. That pairing matters because an incorrect combination can produce tokens that fail verification outside your application.
- Which lcobucci/jwt versions does jdr/jws-ecdsa support?
- The package is built around lcobucci/jwt's Signer abstraction, but the Signer contract and exception types changed significantly across lcobucci/jwt v3, v4, and v5. You should verify the exact pinned version in the package's composer.json before adopting it. On lcobucci/jwt v4 and v5, native Lcobucci\JWT\Signer\Ecdsa classes may already cover the requirement.
- Do I need a ServiceProvider or config file to use jdr/jws-ecdsa in Laravel?
- No. The package is a lightweight adapter rather than a Laravel package with auto-discovered service providers, configuration, or migrations. You integrate it by binding the signer and parsed key in your application container or by configuring an existing JWT package to use it, such as tymon/jwt-auth if the lcobucci/jwt versions are compatible. That keeps it easy to hide behind an internal TokenSigner interface.
- How do I generate ECDSA keys for JWS signing?
- Generate EC key pairs with OpenSSL using the curve that matches your algorithm, such as prime256v1 for ES256, secp384r1 for ES384, or secp521r1 for ES512. Keep the private key in secure storage and expose only the public key to verifiers, ideally through a JWKS endpoint. Key generation is only one part of the lifecycle; plan rotation, kid values, and distribution before production. Verify OpenSSL with EC support in FPM, containers, CI, and workers, since minimal images can lack the required curves.
- Is jdr/jws-ecdsa production-ready?
- Treat it as source code rather than a heavily vetted dependency. The project has very low community signal, a single maintainer, and no release cadence, so production adoption carries supply-chain risk. For many teams, vendoring a small first-party signer modeled on the package or using native lcobucci/jwt ECDSA support is safer.
- How do I test jdr/jws-ecdsa tokens?
- Test by signing a known payload and verifying it with an independent verifier, not only by round-tripping through the same code path. For JOSE compatibility, check that the signature is encoded as fixed-width raw R||S rather than OpenSSL's DER format, and confirm the curve and hash pairing for each algorithm. Also validate against every external consumer that will receive your tokens.
- What are the alternatives to jdr/jws-ecdsa?
- If you are on lcobucci/jwt v4 or v5, the native Lcobucci\JWT\Signer\Ecdsa classes are the first alternative and remove the extra dependency. Another option is writing a small first-party signer that handles the required curves and JOSE raw R||S encoding. For broader JWT features, evaluate maintained libraries such as lcobucci/jwt itself or firebase/php-jwt where they fit your stack.
- Does jdr/jws-ecdsa support KMS, HSM, or FIPS requirements?
- No. The package is a software ECDSA signer built on OpenSSL and does not provide KMS, HSM, or FIPS-backed key operations. If your requirements mandate hardware-backed keys or FIPS posture, neither this package nor lcobucci/jwt covers them out of the box and the scope changes materially. You would need to integrate with a cloud KMS or HSM provider instead.