Integrity Failures in Axum with Jwt Tokens

In Axum, integrity failures related to JWT tokens occur when a service accepts and acts upon tokens that are not verifiable as authentic and unmodified. This typically happens when token validation is incomplete or misconfigured, allowing an attacker to supply a token with a weak or missing signature, an incorrect algorithm, or tampered claims. Axum applications that parse and validate JWTs must ensure the token’s signature is verified using the correct key and algorithm before trusting any contained identity or authorization information.

One common pattern that leads to integrity issues is using a symmetric secret for signing but accidentally accepting tokens signed with asymmetric algorithms such as RS256 without proper key resolution. If an application does not enforce algorithm consistency, an attacker can provide an RS256-signed token with a public key as the signature and the application may incorrectly validate it against a shared secret, resulting in privilege escalation or unauthorized access.

Another scenario involves missing or weak audience (aud) and issuer (iss) checks. Without validating these claims, a token issued for one service or audience might be accepted by another service, undermining token scope and enabling cross-service impersonation. Similarly, if the application does not validate token expiration (exp) and not-before (nbf) claims, it may accept expired or not-yet-valid tokens, increasing the window for replay or delayed attacks.

Middleware implementation plays a critical role. If the JWT validation middleware is applied inconsistently—such as being omitted on certain routes or applied after authorization checks—an attacker can bypass intended protections by targeting unprotected endpoints. Incomplete error handling can also leak information about token validation failures, aiding further exploitation.

Real-world attack patterns include token substitution, where an attacker replaces a valid token with another signed with a weak algorithm, and algorithm confusion, where the server is tricked into verifying a token with the wrong cryptographic assumptions. These map to common weaknesses in API security and can lead to unauthorized access, data exposure, and integrity violations.

To remediate integrity failures when using JWT tokens in Axum, enforce strict validation rules and use well-maintained libraries such as jsonwebtoken with explicit configuration. Always specify the expected algorithm and validate all standard claims, including issuer, audience, and expiration.

Example of secure JWT validation middleware in Axum using the jsonwebtoken crate:

use axum::{routing::get, Router, extract::Extension};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation, TokenData};
use serde::{Deserialize, Serialize};
use std::net::SocketAddr;

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    aud: String,
    iss: String,
    exp: usize,
    nbf: usize,
}

async fn handler(Extension(token_data): Extension<TokenData<Claims>>) -> String {
    format!("Authenticated: {}", token_data.claims.sub)
}

#[tokio::main]
async fn main() {
    let secret = std::env::var("JWT_SECRET").expect("JWT_SECRET must be set");
    let audience = std::env::var("JWT_AUDIENCE").expect("JWT_AUDIENCE must be set");
    let issuer = std::env::var("JWT_ISSUER").expect("JWT_ISSUER must be set");

    let validation = Validation::new(Algorithm::HS256);
    let mut validation = validation;
    validation.validate_exp = true;
    validation.validate_nbf = true;
    validation.validate_aud = true;
    validation.validate_iss = true;
    validation.audience = audience.as_str().into();
    validation.issuer = issuer.as_str().into();

    let decoding_key = DecodingKey::from_secret(secret.as_ref());

    let app = Router::new()
        .route("/protected", get(handler))
        .layer(Extension(decode("your.jwt.token.here", &decoding_key, &validation).expect("Invalid token")));

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

Key points in this example:

• Algorithm is explicitly set to HS256 via Validation::new(Algorithm::HS256) to prevent algorithm confusion attacks.
• Audience and issuer are validated against configured values, preventing token misuse across services.
• Expiration (exp) and not-before (nbf) checks are enabled to avoid accepting outdated or future-dated tokens.
• The decoding key is derived from a secret, and the token is decoded before being passed to handlers, ensuring only valid tokens are processed.

For production, load the secret and claims configuration securely, rotate keys periodically, and ensure errors from invalid tokens do not expose stack traces or internal details. Using the Pro plan with continuous monitoring can help detect patterns of invalid token submissions that may indicate active integrity attacks.