Conversion between `Algorithm` and `KeyAlgorithm`

[BatmanAoD]

The Algorithm and KeyAlgorithm types seem closely related to me, since a JWK is used to verify a JWT, and the signing algorithm must match the verification algorithm. It seems that the crate is mostly built around Algorithm, but given a Jwk, I don't see a way to determine the supported Algorithm other than by manually converting jwk.common.key_algorithm (a KeyAlgorithm) into an Algorithm using an explicit match (and erroring on any of the variants that are not in Algorithm).

Is there a reason why the two types are separate, and why the crate itself does not provide conversions between them? If not, can impl TryInto<Algorithm> for KeyAlgorithm and Into<KeyAlgorithm> for Algorithm be added?

[arckoor]

KeyAlgorithm has more values than Algorithm to allow deserialization of certain JWKs, even if we don't support that particular algorithm
The token should specify alg either way, and to find the correct JWK you're already filtering by something like kid I assume? What's the use case of knowing the algorithm ahead of time when you need to decode the header of the JWT anyway?

[BatmanAoD]

Our decoding logic is effectively something like this:

pub fn parse_jwt(&self, token: &str) -> Result</*user data*/, Error> {
    let jwk = /* lookup by kid */;
    let decoding_key = DecodingKey::from_jwk(&jwk)?;
    let key_algo = jwk.common.key_algorithm.ok_or(/*error*/)?;
    let algorithm = key_algorithm_to_algorithm(key_algo)?; // < where we would use TryFrom
    let mut validation = Validation::new(algorithm);
    // ... add validation fields
    let raw = decode(token, decoding_key, validation)?;

    // build user data from claims & header
}

Should we be using Validation::new_for_family(decoding_key.family()) instead?

[arckoor]

You already have let jwk = /* lookup by kid */;, which I assume comes from a let header = decode_header(token).unwrap(), in which case just use header.alg? Basically what the auth0 example does

[BatmanAoD]

Ah, okay, I didn't see header.alg; thanks.

There's an additional wrinkle, which is that, currently, we build the DecodingKey and Validation for each jwk once, on start-up. I'm assuming that building the Validation is cheap, so it may be fine to just build that on demand for each JWT we receive, but since the set of JWKs we have tells us exactly which algorithms we're able to use, it seems odd that building these in advance wouldn't be supported.

So the actual logic is more like:

pub fn build_jwt_parsers() -> Result<HashMap<String, (DecodingKey, Validation)>, Error> {
    let jwk_set = /* request JWKs from OIDC provider */;
    jwk_set.keys.into_iter().map(|jwk| {
        let decoding_key = DecodingKey::from_jwk(&jwk)?;
        let algorithm = key_algorithm_to_algorithm(key_algo)?; // < where we would use TryFrom
        let mut validation = Validation::new(algorithm);
        // ... add validation fields
        Ok((decoding_key, validation))
    }).collect()
}

pub fn parse_jwt(keys: HashMap<String, (DecodingKey, Validation)>, token: &str) -> Result</*user data*/, Error> {
    let header = decode_header(token)?;
    let (decoding_key, validation) = keys[header.kid.ok_or(/*error*/)?;
    let raw = decode(token, decoding_key, validation)?;

    // build user data from claims & header
}

[arckoor]

Validation is meant to be constructed at the start (because it actually isn't that cheap, it has a HashSet), so that is a very valid point

[BatmanAoD]

Thanks very much! Any thought on when you might publish the next release?

[arckoor]

I want to try and get #475 and maybe #506 in since they have more breaking changes, but if they are stalled for a long time they'll get merged later
I definitely want to avoid waiting until July at the very least