Signature padding problem?
Issue #161
resolved
I have a JWT token extraction method that works perfectly on my localhost tests, but which fails on production with the error message:
org.jose4j.jws.RsaUsingShaAlgorithm$RsaSha256 [debug] Problem verifying signature: java.security.SignatureException: Signature length not correct: got 511 but was expecting 512
The difference being only one character, I was wondering if it was some kind of padding issue, once the signature has been decoded from base64. I would also welcome any suggestion in trying to diagnose the problem (I can add some log, and even use a patched jose4j version for that matter, but I cannot put breakpoints in production).
Attached are the source of the JWT extraction method and the logs. Thanks for any help.
Comments (6)
-
repo owner
-
repo owner
The length of an RSASSA-PKCS1-v1_5 signature is always equal to the size of the RSA modulus (per https://tools.ietf.org/html/rfc3447#section-8.2 and https://tools.ietf.org/html/rfc3447#section-4.1 which is what JWA/JWS/JWT reference for RS256 etc.) so assuming an 4096 bit RSA key was used here the length of the signature has to be 4096 bits as well (which is 512 bytes). The base64url encoded signature part of the ID token is 682 characters, which decodes to 511 bytes and isn't valid for the reasons previously stated.
-
repo owner
In general, for JWT processing, you might want to consider using a
JwtConsumer(see https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples) rather than directly using theJsonWebSignatureclass. Although that won’t help with what appears to be an invalid signature. Unless you set up theJwtConsumerto skip signature validation all together. And because it looks like you’re getting this ID token directly from the token endpoint, that might be okay to do. -
reporter
Thanks for the details. I’ll continue to investigate and let you know.
-
reporter
Bug found and fixed. Yes, the base64url encoded string was erroneously stripped down from its last character in the upstream code because of a buggy buffering implementation. Thanks for your help.
-
reporter
- changed status to resolved
Bug was in client code.
- Log in to comment
I’m a bit perplexed to be honest. But it looks like it might be a problem with signer of the JWT.
Was this a one-time thing? Intermittent? Consistent? All the time?
Can you provide the public key used for verification too?
What system or software or library or whatever is creating the JWT? Is that different between your tests and prod?