Validate a token with no base 64 signin key

[marinobmp]

Hello, I'm issuing tokens from a java web app without encoding base 64 the key
.signWith(SignatureAlgorithm.HS512, jwtSigningKey)

I am trying to validate the token on php like this:

$parser = new Lcobucci\JWT\Token\Parser(new Lcobucci\JWT\Encoding\JoseEncoder());
$token = $parser->parse($jwt);

$validator = new Lcobucci\JWT\Validation\Validator();
$clock = new Lcobucci\Clock\SystemClock(new DateTimeZone("Europe/Berlin"));
$constraints = [
	  new Lcobucci\JWT\Validation\Constraint\SignedWith(new Lcobucci\JWT\Signer\Hmac\Sha512(),
	      Lcobucci\JWT\Signer\Key\InMemory::plainText($SECRET_KEY)),
	  new Lcobucci\JWT\Validation\Constraint\LooseValidAt($clock)
];

try {
	  $validator->assert($token, ...$constraints);
	  // Token is verified
	  return $token;
} catch (Lcobucci\JWT\Validation\RequiredConstraintsViolated $e) {
	  // Invalid token.
	  return false;
}

but it says that "Token signature mismatch"

Changing the way I generate the token on java to this:
.signWith(SignatureAlgorithm.HS512, TextCodec.BASE64.encode(jwtSigningKey))

works like a charm. But the problem is that I cannot change the token generation in java. Any help here, please? How can I avoid the base64 decoding when parsing the token? Thank you!

[SvenRtbg]

The HS512 algorithm supposedly just uses the string you pass. So if your JWT exchange only works if you base64 encode the signing key on Java side, maybe think about how that key got into PHP, and maybe use base64decode before you pass the key into the signing. You could also use base64Encoded() instead of plainText() to base64-decode the key right away.

To rephrase it: The key has no formal format to follow for this algorithm besides being of a minimum length it bits, so it does not matter if a string of a certain length does not contain any nonprintable characters because that was the random output, or because it is the result of base64-encoding binary output. Base64encoded strings are longer in character count, so the process would not fail because of a too short key string. It will not fail because of invalid inner format (RSA for example uses the openssl extension and requires a certain text format for the key string). So it seems to just fail validating the signature, but in reality it is simply using a different key.

[SvenRtbg]

In fact that string can be decoded in non-strict mode and even returns something sensible (i.e. about 574 bits of binary data). Recoding the result reveals that the demo string here is simply missing one "D" at the end to be a valid base64 encoded string.

[marinobmp]

Hi guys,

@lcobucci yes, that the secret I'm using on my local environment:
AAAAAAAAABBBBGGGGGGGGKKKKKKKKKKKKKRRRRRRRRRRWWWWWWWWWWWWWWWWWWWWWWWWWWDDDDDDDDDDDDDDDDDDDDDDDDDDD

You can use jwt.io and this lib to verify that there's interoperability between them for both plain and b64 encoded secrets.

I have check and I can validate at using the key as it is:
AAAAAAAAABBBBGGGGGGGGKKKKKKKKKKKKKRRRRRRRRRRWWWWWWWWWWWWWWWWWWWWWWWWWWDDDDDDDDDDDDDDDDDDDDDDDDDDD

and checking the base64 checkmark as in the image before:

what other check should I do?

If you are indeed using a binary value as KEY in Java, encode it in b64 so you are able to bring it to PHP (keep it in binary form in Java).

Unfortunatelly I cannot change the way the tokens is generated in java

@SvenRtbg thank's again. But I don't understand ... there is no missing D. The secret I'm using on my tests here is that one as is ...

Sorry guys, but I do not understand what am I doing wrong, and I need this to work ... :(

Your help is much appreciated

[SvenRtbg]

I'm trying to illustrate the issue with that external link to a well-known PHP sandbox service: https://3v4l.org/kiMaF

Code in the sandbox:

<?php

$key = "AAAAAAAAABBBBGGGGGGGGKKKKKKKKKKKKKRRRRRRRRRRWWWWWWWWWWWWWWWWWWWWWWWWWWDDDDDDDDDDDDDDDDDDDDDDDDDDD";
var_dump(base64_decode($key));
var_dump(base64_decode($key, true)); // This is what JWT lib is using.

$newKey = base64_encode(base64_decode($key));
var_dump($key, $newKey);

var_dump(base64_decode($newKey));
var_dump(base64_decode($newKey, true)); // This is what JWT lib is using.

And my output is:

string(72) "�A�a��a����(��(��(�QE�QE�QYe�Ye�Ye�Ye�Ye�Ye�Y`�0�0�0�0�0�0�"
bool(false)
string(97) "AAAAAAAAABBBBGGGGGGGGKKKKKKKKKKKKKRRRRRRRRRRWWWWWWWWWWWWWWWWWWWWWWWWWWDDDDDDDDDDDDDDDDDDDDDDDDDDD"
string(96) "AAAAAAAAABBBBGGGGGGGGKKKKKKKKKKKKKRRRRRRRRRRWWWWWWWWWWWWWWWWWWWWWWWWWWDDDDDDDDDDDDDDDDDDDDDDDDDD"
string(72) "�A�a��a����(��(��(�QE�QE�QYe�Ye�Ye�Ye�Ye�Ye�Y`�0�0�0�0�0�0�"
string(72) "�A�a��a����(��(��(�QE�QE�QYe�Ye�Ye�Ye�Ye�Ye�Y`�0�0�0�0�0�0�"

This lib is using the second base64_decode with true as second argument and returns false. That triggers the exception.
If I decode without strict mode and reencode, the resulting string is one D longer. And that new string can be decoded in strict mode. As you can see, the result in binary looks the same after reencoding. So that may be the result of a faulty base64 encoding inside Java, or a simple copy/paste error of the base64-encoded key string.

[SvenRtbg]

I just realize: The new key is one D shorter? That makes even more sense given that base64_decode will drop non-matching characters in non-strict mode. Whatever - your string is an incorrect base64 string, and JWT complains about that. I'd ask you to verify you actually get that string.

[marinobmp]

Hello, I've fixed it! Thank you very much for your patient!

Using a base64 encoded string that I generated with https://www.base64encode.org

and using InMemory::base64Encoded did the trick.

I was using on java side a random string and not a valid base 64 encoded one