SignatureException: JWT signature does not match locally computed signature

[kalidasstamil]

We generate keypair to sign the jwt token with private key and parse the claims using public key. Public key is being converted as string using following code and stored in cache to verify,
String keyStr = pub.getModulus().toString().trim() + "|" + pub.getPublicExponent().toString().trim();
when verify the signature using below code to build public key,

String[] parts = keyStr.trim().split("\\|");
RSAPublicKeySpec spec = new RSAPublicKeySpec(new BigInteger(parts[0].trim()), new BigInteger(parts[1].trim()));
Key key = KeyFactory.getInstance("RSA").generatePublic(spec);

Using Keylocator LocatorAdapter<Key> to verify and parse the claim,
Jws<Claims> jwtClaims = Jwts.parser().keyLocator(publicKeyLocator).build().parseSignedClaims(token);

it works fine sometime. But, the code throws SignatureException: JWT signature does not match locally computed signature randomly. This issues is completely random. Not sure what's the reason? Any limitation with the library? or any code issue from my side?

Note: using jjwt 0.12.3

[lhazlewood]

We haven't experienced any problems in JJWT before with random public key data working sometimes and not working during other times. Odds are very high that there's a problem with creating the RSAPublicKeySpec correctly and/or saving or parsing the String data correctly.

For example, in most cryptographic contexts where a BigInteger is required, the data represents unsigned bytes, so we always use the BigInteger(1, bytes) constructor:

jjwt/impl/src/main/java/io/jsonwebtoken/impl/lang/BigIntegerUBytesConverter.java

Line 53 in d4a0827

return new BigInteger(1, bytes);

Converting the BigInteger values to a numeric String, trimming and then back again could be problematic. In crypto contexts, the magnitude bytes are almost always Base64(Url)-encoded before storage instead of using bigInteger.toString(). See the BigIntegerUBytesConverter.java class linked above for an example of getting the bytes (which are in turn Base64URL-encoded/decoded).

[lhazlewood]

No reply from OP in two weeks, marking answer. Feel free to post follow ups to this thread if needed!

[lhazlewood]

@kalidasstamil Any update or reply to my post above?