JWT woes - crypto issues?

[Igor Clark]

Yes just checked again to be 100% sure. Using identical keys, literally copy-pasted from one to the other, the Python library generates token signatures that it validates itself and which are validated by jwt.io with the public key, but which the erlang one says is invalid, with the same key; the erlang one generates token signatures that it validates itself, but which python and jwt.io say are invalid. I guess it's looking more and more like it's just the jwerl lib, or just the es384 routine, but that still makes me wonder if it's something about the underlying crypto stuff being used.

However, just to check, I ran the erlang version in a docker image with Debian 10, and that had exactly the same problem. So probably not to do with underlying OS crypto if it's the same on both ...

Really puzzled!

> On 5 Feb 2021, at 20:10, Igor Clark <igor.clark@REDACTED> wrote:
> 
> Thanks Łukasz,
> 
> I could have made a mistake for sure! But I'm as sure as I can be - that was pretty much the first thing I checked.
> 
> The Python is using the base64-encoded string copied from the PEM file, which works, generating JWTs that jwt.io validates successfully from the paired public key.
> 
> The Erlang jwerl code is using the same base64-encoded string in a binary (ie <<"-----BEGIN EC PRIVATE KEY-----\nMIGkAgEBBDAt8OrDBu"...>>), because that's the only way the library would accept it, and because when I looked in the code for jwerl I saw it was using public_key:decode_pem/1 directly on the passed-in key, so it seemed like that was the right format to use.
> 
> Cheers,
> Igor
> 
>> On 5 Feb 2021, at 19:47, Łukasz Niemier <lukasz@REDACTED> wrote:
>> 
>> Are you sure that the secret is the same and is passed in the format that both libraries expect? Because one may require Base64 encoded string and other will require to pass raw data. 
>> 
>> --
>> Łukasz Jan Niemier
>