Question: validating tokens issued with asymmetric keys

[andrei-dascalu]

Hello,

I have a case where I need to validate a token issued by someone else simply by using the provided public key of the pair.

In 'ye olde days', I'd parse the token with an anonymous parser and then I'd call ->verify(my signer, public key).

Now it seems like the verify has been deprecated and it's not clear for me how I should go about simply verifying a token using a known algorithm and just a public key (in configuration for asymmetric, the second param is the private key and it's not optional).

I feel a bit dumb but as far as this scenario goes I haven't managed to find a working way looking through the docs.

[lcobucci]

Hey @andrei-dascalu 👋
I took the liberty of converting the issue into a discussion to make things easier to track and categorise 😄

Disclaimer: my documentation skills are something that I'm still working on and am quite sorry that things there gave you that feeling.

To increase the cohesion of the API, we indeed extracted the validation logic to a different set of objects.
We now have the Validator and the Constraints.

The overview can be seen in https://lcobucci-jwt.readthedocs.io/en/stable/validating-tokens/.
In the examples, we use the configuration object. I thought that this would help things but you're not the only one confused by where the configuration comes from (or even what is that hypothetical DI container doing there).

Is it mandatory to use the configuration object?

No! You're free to instantiate the objects yourself. The named constructors there also focus on the general scenario of the lib (your app is the issuer and the consumer).

If you want to use the configuration object but are only performing the issuing on verification, you can use an empty signature:

// Configuration focused on issuing only.
// If you try to use $config->verificationKey() and $config->signer() to verify a token the validation will fail
$config = Configuration::forAsymmetricSigner(
    new Eddsa(), // EdDSA is only available from v4.1+ but highly recommended =)
    InMemory::plainText('my-very-secure-key-for-signing-tokens'),
    InMemory::empty(),
);

// Configuration focused on verification only.
// If you try to use $config->signingKey() and $config->signer() to issue a token the process will fail
$config = Configuration::forAsymmetricSigner(
    new Eddsa(),
    InMemory::empty(),
    InMemory::plainText('my-public-key-for-verifying-tokens'),
);

Using the validator directly

Since the configuration object is optional, you can instantiate the components according to your needs:

// $token in this snippet is an already parsed JWT 👍

$validator = new Validator();

// Returns true/false if the token as been issued with that key pair
$validator->validate(
    $token,
    new SignedWith(
        new Eddsa(),
        InMemory::plainText('my-public-key-for-verifying-tokens')
    )
);

// Throws an exception if the token has NOT been issue with that key pair
$validator->assert(
    $token,
    new SignedWith(
        new Eddsa(),
        InMemory::plainText('my-public-key-for-verifying-tokens')
    )
);

You may pass multiple constraints to the validator methods if needed - including custom constraints, quite handy when you have special rules about claims that must be present.

I hope that helps!
If you think the documentation can be improved, please send PRs!

[Ocramius]

Do you have a full trace, exception type and message? Something really fishy happening with that error message O_o

[madsongr]

That error is ok now. This morning I opened the VS Code and Eddsa was an option from use Lcobucci\JWT\Signer\. Yesterday only Ecdsa was available.

I'll try to decode the token now. Thanks for your reply.

[madsongr]

I have a doubt. I need to generate a token to sign my users in Google Firebase using signInWithCustomToken().

I think I should generate a token with new Signer\Rsa\Sha256(), right?!

If so, I should use new Signer\Rsa\Sha256() to decode it, right?! Or should I use `new Eddsa() to decode it?

[lcobucci]

@madsongr I don't know which algorithm is used by Google Firebase but you certainly need to verify the signature using the same algorithm used to sign the token.

[iamtommcc]

To add on to the helpful answer above: it's worth noting that in version 5, the above example doesn't work as InMemory::empty() is no longer available. You can substitute this with an arbitrary key (e.g. InMemory::plainText('empty')) instead.

I'm not certain this is a great approach, but it seems to be what at least some other major libraries are doing under the hood

@lcobucci I reckon it might be worth adding an example to the docs which covers this scenario. Verifying JWT signatures from external systems when you don't have the private key seems to be a common use case but it took quite a bit of digging to figure out what to do in this case.