Skip to content

feat: Support RS384/RS512 and PS256/PS384/PS512 JWT signature algorithms#1991

Open
NiklasHerrmann21 wants to merge 1 commit into
mainfrom
feature/jwt-rsa-algorithms
Open

feat: Support RS384/RS512 and PS256/PS384/PS512 JWT signature algorithms#1991
NiklasHerrmann21 wants to merge 1 commit into
mainfrom
feature/jwt-rsa-algorithms

Conversation

@NiklasHerrmann21

Copy link
Copy Markdown
Contributor

Summary

Adds support for five additional RSA-based JWT signature algorithms in JwtSignatureValidator:

  • RS384, RS512 — RSASSA-PKCS1-v1_5 with SHA-384 / SHA-512 (RFC 7518 §3.3)
  • PS256, PS384, PS512 — RSASSA-PSS with SHA-256 / SHA-384 / SHA-512 (RFC 7518 §3.5)

RS256 continues to work unchanged.

What changed

  • JwtSignatureAlgorithm (enum) now declares all six algorithms with the JCA name passed to Signature.getInstance(...) and, for PSS, the appropriate PSSParameterSpec.
  • JwtSignatureValidator#validateSignature calls Signature#setParameter(...) when the selected algorithm carries a parameter spec. RSA-PKCS1 paths are unchanged.
  • JwtSignatureAlgorithm#fromType is now an explicit RSA → RS256 mapping. Previously the answer depended on enum declaration order, which would have silently changed semantics as new algorithms are added.

What did not change

  • The validator still only accepts algorithms it has been told about; an unknown alg in the JWT header is rejected with the existing JWT token validation with signature algorithm '...' is not supported. error.
  • No changes to JWK parsing — all six algorithms use kty=RSA, so JsonWebKeyImpl#createRSAPublicKey covers them.

Test plan

  • mvn -pl java-security test — green, 16 new parameterized tests in JwtSignatureAlgorithmTest
  • mvn install -DskipTests (full repo compile) — green
  • New tests round-trip a freshly generated RSA key pair through every declared algorithm (validateSignature_acceptsTokenSignedWithAlgorithm) and verify that a tampered payload is rejected (validateSignature_rejectsTamperedToken)
  • Algorithm-confusion safety: the algorithm is taken from the JWT header but only used as a lookup key into the enum; we never trust an attacker-supplied algorithm name verbatim, and the PSS parameter spec is fixed per enum entry rather than driven by header values

Out of scope

ECDSA algorithms (ES256, ES384, ES512) require a separate JWK key-type path (kty=EC with crv, x, y) and additional curve mapping. They will be addressed in a follow-up PR.

Companion ticket

Lifts the supported-algorithm set toward parity with the node.js library (which gained RS384/RS512 in 4.0.0) and prepares the way for PS* and ES* coverage.

The JwtSignatureValidator previously only accepted RS256-signed tokens.
Extend JwtSignatureAlgorithm with the five additional RSA-based algorithms
from RFC 7518 §3.3 (RSASSA-PKCS1-v1_5 with SHA-384/SHA-512) and §3.5
(RSASSA-PSS with SHA-256/SHA-384/SHA-512), and set the corresponding
PSSParameterSpec on the JCA Signature instance for the PS* variants.

Algorithm selection is driven by the JWT header `alg` value; unknown
values continue to be rejected with the existing "is not supported"
error path.

Also tightens JwtSignatureAlgorithm.fromType to an explicit mapping
(RSA -> RS256, everything else -> null) so the JWK fallback semantics
do not depend on enum declaration order as new algorithms are added.

Parameterized tests verify that every declared algorithm round-trips
through validateSignature with a freshly generated RSA key pair, and
that a tampered payload is rejected for each algorithm.

ECDSA algorithms (ES256/ES384/ES512) will follow in a separate PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant