feat: JWT verification builtins (#94)

[wetpeanuts]

Implemented:

• Implemented builtins: io.jwt.[decode|decode_verify|verify_xxxxx] (except verify_eddsa)
• Fully passed OPA tests: jwtbuiltins, jwtverifyhs[256|384|512], jwtverifyrsa
• Partially passed OPA tests: jwtdecodeverify (the ones that leverage io.jwt.verify_eddsa and io.jwt.encode_sign still do not pass)
• In order to enable customization of the crypto libraries behind JWT verification algorithms, this implementation introduces JWT Backend trait that describes common interface for JWT verification. The trait can be implemented using variable libraries, depending on user needs. The exact trait implementation is selected based on a feature provided to compiler. Currently only 1 inplementation of the JWT Backend is available (leverages OpenSSL as underlying crypto lib).

To be implemented in the follow up PRs:

• verify_eddsa support and token encoding builtins.

Note that I've also modified the implementation for opa tests in order to be able to run each test separately, not sure if it really belongs here.

Looking forward for a feedback

[wetpeanuts]

@microsoft-github-policy-service agree

[anakrish]

Hey @wetpeanuts,

Thank you for the contribution!

1. Some of the failures are due to out of date lock files. There is now an experimental cargo xtask update-deps that should update the relevant lock files once the root Cargo.toml has been changed. If that doesn't work, each folder within bindings needs to be updated manually by running cargo update.
2. It looks like the windows build runners don't have openssl installed. That causes the other failures.
   Maybe we could start off by disabling this feature in the bindings, make sure that it works with Rust only usage, and then later enable it for the bindings.
3. Can we ensure that we are using OpenSSL 3.x? Anything below is not approved for use at MSFT.

[wetpeanuts]

Hey @anakrish

Thank you for the feedback

1. Guess I need to rebase to the latest main and use it. I'll give it a try.
2. I actually plan to introduce another Rust only JWT backend in the next iteration and use it as default. I agree that using OpenSSL by default is probably not the best idea since it might be missing in some environments.
3. I'll check how we can ensure using OpenSSL 3.x.

[anakrish]

Hey @wetpeanuts,

Given MSFTs constraints on FIPS certification etc, we will likely want OpenSSL 3.x as the default. But having a rust only option is also good for other consumers of the crate.

Another approach to consider is whether a registration mechinasm can be provided to install an instance of the trait for use as the crypto implementation.