fix: update JWK secret handling to separate private and public keys #118

[FairyScript]

Summary by CodeRabbit

• Refactor
  • Improved internal key handling so signing and verification use distinct private/public key material; transparent to users and no changes to the public API or existing integrations.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Introduces separate privateKey and publicKey derived from the secret value; signing operations use privateKey, verification uses publicKey. The observable key flow changes from a single key to a two-step secret -> privateKey -> publicKey pathway. No exported API signatures changed.

Changes

Cohort / File(s)	Summary
Key material separation for signing and verification src/index.ts	Adds extraction/derivation of privateKey and publicKey from secret; updates sign() to use privateKey and verify() to use publicKey instead of a single key variable. No changes to public API signatures.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20–30 minutes

• Inspect privateKey derivation when secret represents a full private key object vs encoded secret string.
• Verify correct derivation of publicKey (stripping private exponent when appropriate) and fallback behavior when privateKey is identical to publicKey.
• Confirm sign() uses privateKey in all branches and verify() uses publicKey in all branches.
• Check for any edge cases around encoding/decoding, key formats, and algorithm compatibility.

Poem

🐇 I nibbled at the secret, pulled a key apart,
One for signing softly, one for public art.
A hop, a byte, a careful little tweak—
Now signatures dance, and verifications speak. 🎩✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: separating private and public key handling in JWK secret processing, which aligns with the primary modifications shown in the raw summary.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d9d24e1 and ea014a4.

📒 Files selected for processing (1)

• src/index.ts (3 hunks)

🔇 Additional comments (2)

src/index.ts (2)

365-365: Correct use of privateKey for signing.

The sign operation now properly uses privateKey, which aligns with the intended separation of key material.

---

380-381: Correct use of publicKey for verification.

Both verification paths now properly use publicKey, which is the correct approach for JWT verification. This change establishes the intended separation between signing and verification key material.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c1ef884 and d9d24e1.

📒 Files selected for processing (1)

• src/index.ts (3 hunks)

🔇 Additional comments (2)

src/index.ts (2)

363-363: Signing with privateKey is correct, but depends on line 208 fix.

Using privateKey for signing operations is the correct approach for asymmetric cryptography. However, this change depends on the privateKey variable being properly initialized on lines 206-208.

Once the publicKey derivation logic is fixed, verify that signing works correctly for all supported key types (symmetric HMAC secrets, RSA, ECDSA).

---

378-379: Verification with publicKey is correct conceptually, but depends on line 208 fix.

Using publicKey for JWT verification is the correct approach. For symmetric algorithms (like HS256), the public and private keys will be identical, while for asymmetric algorithms (like RS256, ES256), only the public component should be used for verification.

This implementation is correct in principle, but its correctness in practice depends on the publicKey derivation being fixed on line 208. After fixing that issue, verify the behavior with both symmetric and asymmetric keys.