Insecure Design in Axum with Jwt Tokens

Insecure design in an Axum service that uses JWT tokens often arises from decisions made before any code is written, such as trusting all callers without a clear authorization model or embedding sensitive logic in the client. When JWTs are accepted without strict validation of the issuer (iss), audience (aud), and token binding to the intended resource, an API can accept tokens issued for other services or scopes. Axum applications that deserialize JWTs into claims but do not enforce per-route authorization can conflate authentication with authorization, allowing a caller with a valid token to act beyond their intended permissions.

A common insecure pattern is to verify a signature and then assume the payload is safe to use directly in business logic. For example, an Axum handler might read a user_id from the JWT and use it to construct database queries without checking that the requesting actor is permitted to operate on that resource. This design oversight enables BOLA/IDOR-like access when combined with predictable identifiers. Similarly, failing to enforce HTTPS and using non‑standard clock skew tolerances can expose tokens to replay or interception, and embedding secrets or roles directly in the token payload without server‑side validation can lead to privilege escalation if the token is tampered with.

Another design risk is how middleware pipelines are composed. If JWT validation middleware is placed after routing or business logic, routes that should be protected may be reachable without a verified token. Conversely, validating tokens for every request without scoping checks can lead to over‑privileged service accounts being accepted for user‑specific endpoints. Axum applications that do not explicitly model authorization boundaries per route—using claims such as scopes or roles to gate handlers—effectively design an unauthenticated or over‑privileged attack surface. This becomes critical when integrating third‑party identity providers where token lifetimes and signing algorithms are not strictly constrained, increasing the likelihood of token misuse or substitution attacks.

Remediation centers on strict validation and explicit authorization checks in Axum handlers and middleware. Always validate standard claims (issuer, audience, expiration, and nonce if applicable), enforce HTTPS, and bind tokens to the intended operation using scopes or roles rather than relying on embedded identifiers alone. Use a robust JWT library such as jsonwebtoken with a verified key source and strict decoding settings.

Example: Strict JWT validation middleware in Axum

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

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

async fn validate_jwt(token: &str) -> Result<TokenData<Claims>, jsonwebtoken::errors::Error> {
    let mut validation = Validation::new(Algorithm::HS256);
    validation.set_audience(&["my-api-audience"]);
    validation.set_issuer(&["trusted-issuer.example.com"]);
    validation.required_spec_claims.insert("aud".to_string());
    validation.required_spec_claims.insert("iss".to_string());

    let key = DecodingKey::from_secret("your-256-bit-secret".as_ref());
    decode::<Claims>(token, &key, &validation)
}

async fn handler(claims: Claims) -> String {
    format!("Hello, user: {}", claims.sub)
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/hello", get(|headers: axum::http::HeaderMap| async move {
            let auth = headers.get("authorization")
                .and_then(|v| v.to_str().ok())
                .and_then(|s| s.strip_prefix("Bearer "))
                .unwrap_or("");
            let token_data = validate_jwt(auth).await.expect("Invalid token");
            handler(token_data.claims).await
        }));

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

Example: Enforcing scopes per route in Axum

use axum::{async_trait, extract::FromRequest, http::Request, response::Response};
use std::future::Future;

struct RequireScope(String);

#[async_trait]
impl<S> FromRequest<S> for RequireScope
where
    S: Send + Sync,
{
    type Rejection = Response;

    async fn from_request(req: Request, _state: &S) -> Result<Self, Self::Rejection> {
        // Assume claims are attached in a previous middleware layer
        if let Some(claims) = req.extensions().get::<Claims>() {
            if claims.scopes.contains(&self.0) {
                return Ok(RequireScope(self.0.clone()));
            }
        }
        Err((axum::http::StatusCode::FORBIDDEN, "Insufficient scope")).into_response()
    }
}

async fn admin_route(_scope: RequireScope) -> String {
    "Admin only".to_string()
}

// In route definition:
// .route("/admin", get(|scope: RequireScope| async move { admin_route(scope) }))

These examples show concrete design choices: validating issuer and audience, requiring scopes for privileged routes, and rejecting tokens that do not meet strict criteria. This shifts the design from implicit trust to explicit verification and least‑privilege authorization.