Race Condition in Axum with Jwt Tokens

A race condition in an Axum application that uses JWT tokens typically occurs when token state validation is split across multiple asynchronous steps or cached checks, and an attacker can influence the timing between those steps. For example, consider a scenario where a handler first checks a high-level permission (e.g., "is the token valid?") and then, based on that check, proceeds to perform a sensitive action (e.g., updating a resource or changing ownership). If an attacker can cause the token validation to pass on the first check but then revoke or swap the token between the check and the action, the application may execute the action with an outdated or invalid authorization context. In Axum, this can surface when you perform token validation in middleware or extract claims eagerly, then store claims in request extensions for later handlers, while another concurrent request or a background task modifies shared state (such as a denylist or a per-user resource version) without proper synchronization.

With JWT tokens, the race condition is often about the window between decoding the token and confirming its continued validity in your system. JWTs are typically stateless, so validation focuses on signature, issuer, expiration, and possibly revocation via short lifetimes or external lookups. If your Axum routes rely on a cached or eventually consistent revocation list, an attacker can race: obtain a valid token, trigger a revocation or logout, and then make a request that arrives at the validation layer before the revocation state is fully visible. Because Axum handlers are asynchronous and can execute in parallel, two requests with the same token may see different validation outcomes depending on timing. This can lead to privilege escalation or unauthorized operations when a token that should be invalid is briefly treated as valid.

Another specific pattern involves conditional logic based on claims extracted from JWTs. For instance, a handler might read a "role" claim to decide whether to allow an operation. If the token itself is not re-validated against a live data source shortly before the operation, and if the user’s role or permissions can change concurrently (e.g., an admin is downgraded), a race exists between the permission change and the incoming request. In Axum, if you deserialize claims once and reuse them across multiple async steps without re-checking critical security properties right before the sensitive action, you effectively introduce a time-of-check-to-time-of-use (TOCTOU) window that can be exploited via concurrency. This is especially relevant when combined with stateful elements like rate limiting or session-like revocation checks that are not tightly bound to the token validation step.

Real-world attack patterns mirror general concurrency issues: an authenticated user with a token escalates privileges by timing a permission change between the authorization check and the action, or an unauthenticated attacker exploits a briefly valid token after logout. Because JWTs often carry more claims than server-side sessions, the surface area grows: claims about permissions, scopes, or tenant IDs can be misused if checks are not consistently applied immediately before each decision. In Axum, this emphasizes the need to treat token validation as a per-request, near-point-of-use operation for critical decisions, and to synchronize or isolate shared state that affects validity.

To mitigate race conditions with JWT tokens in Axum, ensure validation is performed as close as possible to the point of use and that any shared state is accessed in a thread-safe, deterministic manner. Prefer verifying the token and extracting necessary claims within the same async block that performs the sensitive operation, and avoid caching or reusing decoded claims across unrelated requests or async boundaries without strong consistency guarantees.

Example: validate the token and check permissions in a single handler, using a service that re-verifies the token and current user state just before the write.

use axum::{routing::post, Router};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation, TokenData};
use serde::{Deserialize, Serialize};
use std::sync::Arc;

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

async fn update_resource(
    State(jwt_key): State<Arc<[u8]>>
) -> Result<impl IntoResponse, (StatusCode, String)> {
    // In a real handler, obtain token from Authorization header
    let token = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...";
    let mut validation = Validation::new(Algorithm::HS256);
    validation.validate_exp = true;
    let token_data: TokenData<Claims> = decode(
        token,
        &DecodingKey::from_secret(&jwt_key),
        &validation,
    ).map_err(|e| (StatusCode::UNAUTHORIZED, e.to_string()))?;

    // Perform critical authorization check right before the action
    if token_data.claims.role != "admin" {
        return Err((StatusCode::FORBIDDEN, "Insufficient scope".to_string()));
    }

    // Proceed with the sensitive operation, ensuring the token is fresh and valid
    // e.g., update resource in DB with user identifier from token_data.claims.sub
    Ok("Resource updated")
}

fn app() -> Router {
    let jwt_key = Arc::new(include_bytes!("key.jwt").try_into().unwrap());
    Router::new()
        .route("/resource", post(update_resource))
        .with_state(jwt_key)
}

If you must check revocation, perform the check in the same handler or via a strongly consistent store lookup immediately before the action, rather than relying on per-request cached flags that can lag. For shared state such as per-user version or denylist, use atomic reads or database transactions with appropriate isolation to ensure the state you observe is the latest when the decision is made.

Additionally, prefer short token lifetimes and use refresh token rotation with strict one-time-use tracking to reduce the window in which a stolen token remains useful. In Axum, structure your routes so that token validation and permission evaluation are not split across multiple middleware layers that may race; instead compose checks inline or via tower layers that execute in a defined order without introducing asynchronous gaps where state can change unnoticed.