Expose cryptography backends via CryptoProvider

[arckoor]

Adds a CryptoProvider struct that allows replacing the built-in providers with something custom.
All the details from this implementation that could be considered "interesting" are stolen straight from rustls's CryptoProvider.

I've marked the new_signer, new_verifier and JWK functions from the two built in backends as pub, so you can do stuff like this:

fn new_signer(algorithm: &Algorithm, key: &EncodingKey) -> Result<Box<dyn JwtSigner>, Error> {
    let jwt_signer = match algorithm {
        Algorithm::EdDSA => Box::new(CustomEdDSASigner::new(key)?) as Box<dyn JwtSigner>,
        _ => jsonwebtoken::crypto::aws_lc::new_signer(algorithm, key)?,
    };

    Ok(jwt_signer)
}

i.e. overwrite just specific algorithms.

One area I'm a little unsure about is JwkUtils, 1) about the name and 2) about the Default implementation. The CryptoProvider::signer_ and CryptoProvider::verifier_factory functions are obviously mandatory for a custom provider, but not everyone uses JWK, so the default just uses dummy functions with unimplemented!().

[arckoor]

@Keats any chance of a review on this?

[drusellers]

Would this allow applications to use rustls rather than openssl?

[arckoor]

@drusellers As far as I know rustls doesn't implement the cryptography directly, rather it relies on other crates like ring, aws-lc-rs, rustcrypto, ...
So you can't really use rustls with this, but you can implement the cryptography with whatever backend you choose, be it openssl, botan, or something else entirely (this crate has aws-lc-rs and rustcrypto built in, using these doesn't require this PR)

[Keats]

I think this can be simplified

[Keats]

that will get more complex if we start supporting some alg in some backend like #461

[Keats]

Do we need that? We should be able to define a DEFAULT_PROVIDER using cargo features I think without needing the dance around that?

[arckoor]

IIUC you mean that it automatically sets PROCESS_DEFAULT_PROVIDER to aws_lc::CryptoProvider if the aws feature is enabled? Yes that could be done, but similar to the JWK utility functions, that would mean you have to replace everything when you implement a custom provider, because otherwise if you select one of the built in features, you'd be locked into that provider.
This way you can implement whatever you want to, enable both aws and custom-provider, and fallback to aws for everything you haven't implemented.

[Keats]

My understanding of custom providers is that you do not want to add the rust-crypto/aws-lc dependencies? That feels a bit awkward otherwise

[arckoor]

I feel that way, yes, others may not, I do not know. I did it this way because rustls did it this way, but I can change it if you want me to.

[arckoor]

All that said while it could be assigned automatically for the rust_crypto and aws_lc_rs features, it still needs to provide a set method for outside crypto providers, and I'm honestly not sure how to do it any other way.

Unless you want a

#[cfg(feature = "custom-provider")]
static PROCESS_DEFAULT_PROVIDER: OnceLock<Arc<CryptoProvider>> = OnceLock::new();

#[cfg(not(feature = "custom-provider")]
# assign from crate features

which I personally think is pretty ugly.

[Keats]

So the way i was thinking about it is that people would create crates like jsonwebtoken-ring, jsonwebtoken-botan that are self contained

[arckoor]

I'm not a fan of that to be honest. I can get behind separate crates as "companion crates" for jsonwebtoken, but doing a passthrough crate is imo a bad idea.
If my project requires two crates that both depend on jsonwebtoken, but use different implementations, i.e. jsonwebtoken-botan and jsonwebtoken-ring, I need to compile two crypto backends, and more importantly I need to trust two crypto backends.

I'd much rather they both require the base jsonwebtoken, and let me select the crypto provider at my crate level, be it a builtin one or one of the custom ones.

[Keats]

I'm not familiar with that pattern of selecting providers like apparently rustls does.

If my project requires two crates that both depend on jsonwebtoken, but use different implementations, i.e. jsonwebtoken-botan and jsonwebtoken-ring, I need to compile two crypto backends, and more importantly I need to trust two crypto backends.
I'd much rather they both require the base jsonwebtoken, and let me select the crypto provider at my crate level, be it a builtin one or one of the custom ones.

What does it look like from the pov of let's say jsonwebtoken-botan implementer and user?

[arckoor]

As the implementer, you define your own crypto provider, and expose it somewhere in your crate.
As a user, you add both jsonwebtoken and jsonwebtoken-botan to your dependencies, and install the provider.
And then it just works.

[arckoor]

@Keats I made the JWK functions private after all. For the PROCESS_DEFAULT_PROVIDER I still think this is the best way to do it, so I left it as is. I also removed the custom-provider feature, because it wasn't really doing anything anymore after making all the things pub / adding getters, so now you users just select neither of the built-in providers.

In regards to the macro, I also left it as is, if #461 goes through and does gate the implementation itself behind a feature, I guess the best would be to remove the macro and write the functions by hand for each built-in provider.

As for the example, I used the botan-rs crate, though I'm not confident you'll like it, it does force devs (and notably CI) to compile botan from source everytime.
That said, I chose it because 1) rust_crypto and aws_ls_rs are already here, and I didn't just want to duplicate the code 2) ring still seems to be unmaintained 3) openssl you have to compile as well and 4) I'm not aware of other solid options.
I feel it might be best to just duplicate the rust_crypto EdDSA implementation for the example, but then I don't know how useful the example is.
A different way to do it would be to introduce an internal __custom_provider_example = [dep:botan] feature, but that doesn't sound too great either :/

[arckoor]

Seems I forgot to bring this up before, but it would really be great if we could do a breaking change to turn this into Result<Vec<u8>>. Everything else lets you return an error should it happen in your custom provider (e.g. botan can technically error here, because it does go through an FFI, and while it shouldn't error, I still need to call unwrap here)