cduvray / jwt-authorizer Goto Github PK

jsonwebtoken exposes the insecure_disable_signature_validation method, that allows for decoding JWTs without validating their signature. This is useful is some use-cases where the service can assume that the token was already validated (in our case, it is done by the service mesh) and only needs to access the encoded claims.

However, from what I can tell from the code here, the Validation is never exposed outside the layer and there is no way to configure it.

On 0.14 token validation fails with an InvalidAudience error when .validation(Validation::new().aud(&[config.audience])) is not set. Prior 0.14 one had to validate audience on its own and skipping .validation was not a problem.

Would have been helpful if this breaking change were mentioned in the CHANGELOG.

jwt-authorizer fails with a AuthErrors::JwksRefreshError: error decoding response body: unknown variant 'RSA-OAEP' when the JWKS URL contains a key where alg is RSA-OAEP.

It seems that https://github.com/cduvray/jwt-authorizer/blob/main/jwt-authorizer/src/jwks/key_store_manager.rs#L182 attempts to ignore a JWK if it's not decodable, but if a serialized JWK is unable to be cast into a JWK in https://github.com/cduvray/jwt-authorizer/blob/main/jwt-authorizer/src/jwks/key_store_manager.rs#L172 (which is the case if it's algorithm is not in https://github.com/Keats/jsonwebtoken/blob/master/src/algorithms.rs#L16), the entire method returns the AuthError.

Tested with a token from Authelia 4.36.4:

{
  "amr": [
    "pwd",
    "hwk",
    "user",
    "mfa"
  ],
  "at_hash": "Fp0dgcb8Rv6z4kpxAWsBmQ",
  "aud": [
    "debug"
  ],
  "auth_time": 1688032822,
  "azp": "debug",
  "client_id": "debug",
  "exp": 1688034654,
  "iat": 1688032854,
  "iss": "https://redacted.idp.example",
  "jti": "sthsth",
  "name": "My Name",
  "preferred_username": "jdreichmann",
  "rat": 1688032822,
  "sub": "redacted"
}

causes INFO jwt_authorizer::layer: err: InvalidToken(Error(Json(Error("invalid type: sequence, expected a space seperated strings", line: 1, column: 75)))), with no Validation configured (just JwtAuthorizer::from_oidc(issuerUrl) and router.layer(auth.layer().await.unwrap()).

In the OpenID Connect Specification 2.2 'aud', the aud (Audience) is described as

In the general case, the aud value is an array of case-sensitive strings.

and further

In the common special case when there is one audience, the aud value MAY be a single case-sensitive string.

However, the current implementation only seems to accept the special case where only a single audience is present. The "expected a space seperated strings" from the error message are not mentioned as a valid representation in the OIDC Specification.

Hi!

When working with multiple OIDC providers it is not clear which OIDC provider url should be passed to the validate function. When working with additional custom validation logic one may want to decode the token first, checking it against a config (e.g. whitelisted oidc providers) and then use this crates validate fn. Could you expose the JWT decoder fn to allow such custom upfront checks?

Sometimes instead of files you have your key material in, say environment variable readily available. It would be nice to allow that kind of functionality.

Similar to KeySourceType::Jwks and KeySourceType::JwksString variants (not sure what your plans regarding that pair are though).

Hi!

I've ran into a scenario where a keycloak instance is running behind a self signed ssl certificate. I am unable to change that fact as it's company policy. They're doing custom CA stuff, blah blah.

So right now I am looking for a way to either configure the reqwest::Client inside the pub async fn discover_jwks(issuer: &str) -> Result<String, InitError> function or pass my own client.

I'd prefer passing one, as I am already creating one for use in other parts of my program.

What do you think?
I'm also more than down to create a pull request to help with this :)

Hello, I would like to know is it possible to set custom error responses instead of default ones? If yes, could you please provide an example?

Hi!

There is a tonic feature flag. I argue that there should be a axum feature flag that is activated by default to not force tonic only users to fetch axum dependencies.

What do you think?

Hi @cduvray,
do you know about the aliri crate? It seems to provide quite a similar feature set as jwt-authorizer.

Serialize is not implemented for types of the standard token claim such as OneOrArray<T> or NumericDate.

I am currently working with https://github.com/mikkyang/rust-jwt for creating some tests based on a self signed token. The lib accepts claims that implement Serialize which means I cannot reuse my custom claims created for usage within jwt-authorizer as they use fields such as NumericDate.

Sometimes you may want more than one possible JWT shapes and authorities.
Setting two (or more) layers will not help, as the outer-most layer will reject the request if the JWT in hand will not validate.
It would be nice to allow combining multiple JwtAuthorizer together to pass the request if either of them validates the JWT successfully.

Hi!

I want to check my custom claim against a predefined config. Therefore I have to move a variable into the closure of `fn check.

https://docs.rs/jwt-authorizer/latest/jwt_authorizer/layer/struct.JwtAuthorizer.html#method.check

But when trying to use a variable within the check callback I am facing closures can only be coerced to fn types if they do not capture any variables

Hi! Nice library. I was trying to use this to write my own extractor for jwt claims from a cookie (with SameSite=Strict) but I noticed that there is no way to get a raw Authorizer. I plan on contributing this, I just wanted to open the issue first.

It would be nice to, rather than outright rejecting missing claims, to only require claims for those handlers that have an extractor for it. Similarly, Option<Claim> should go through as long as there is:

• a) a valid Claim
• b) no token provided at all

With a little tweaking (namely removing the 'missing' error variant) we can get part-way there, but because we simply return a 500 error when we can't get the token, it fails. I think the solution is to keep the missing variant, and have AuthError be the rejection type for the extractor as well, rather than just the middleware.