Insufficient Logging in Fastapi with Jwt Tokens

Insufficient logging in FastAPI applications that use JWT tokens can significantly weaken security visibility and incident response. When JWT-based authentication is in place, requests are often considered authenticated once a valid token is verified. If logging is incomplete or inconsistent, security teams lose the ability to reconstruct authentication events, detect abuse, and investigate compromised tokens.

In a FastAPI app using JWT tokens, common gaps include missing token metadata, lack of structured audit trails for token validation outcomes, and absence of correlation identifiers across services. For example, logging only the user ID from a decoded token while omitting the token’s jti (JWT ID), issuer, audience, and expiration makes it difficult to detect token replay, token leakage, or use of revoked tokens. An attacker who steals a JWT can reuse it until expiration; without detailed logs that include token identifiers and scopes, detecting such misuse is difficult.

Another specific risk arises when FastAPI middleware validates JWTs but does not log validation failures with sufficient context. Silent failures or generic error responses prevent detection of brute-force or token-guessing attempts. Without logs that capture the token header or at least the token type and issuer, it is harder to identify patterns such as malformed tokens or unexpected signing algorithms that may indicate an attack.

Operational blind spots also occur when logs capture success states but omit key security signals, such as whether elevated scopes or administrative claims were present in the JWT. This becomes critical in scenarios involving token impersonation or privilege escalation, where an account with limited permissions uses a token with broader scopes. If logs do not record the scopes and roles embedded in the JWT, anomalous use may go unnoticed until a breach is confirmed through other means.

middleBrick scans can surface these logging gaps as part of the Data Exposure and Authentication checks, highlighting missing audit fields and inconsistent error handling in unauthenticated scans. By correlating spec definitions with runtime behavior, the tool can point out where token-related events are not sufficiently recorded, enabling teams to strengthen observability without exposing sensitive data.

Remediation focuses on structured, secure logging of JWT validation events while avoiding token leakage. In FastAPI, this can be implemented in dependency functions and middleware to ensure key token attributes are recorded and failures are explicitly logged.

Below is a secure FastAPI dependency that validates JWT access tokens and logs detailed, privacy-safe audit information. It records token metadata and validation outcomes without storing raw tokens or sensitive claims in logs.

import logging
import time
from typing import Optional
from fastapi import Depends, HTTPException, status
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
import jwt  # PyJWT

logger = logging.getLogger("api.audit")
security_scheme = HTTPBearer()

def decode_token(token: str) -> Optional[dict]:
    try:
        # Use issuer, audience, and key rotation best practices in production
        decoded = jwt.decode(
            token,
            options={"verify_signature": True, "require": ["iss", "aud", "exp", "iat", "jti", "scope"]},
            algorithms=["RS256"],
            issuer="https://auth.example.com",
            audience="api.example.com",
            # In production, use a key set or JWKS endpoint
            key="-----BEGIN PUBLIC KEY-----...-----END PUBLIC KEY-----"
        )
        return decoded
    except jwt.ExpiredSignatureError:
        logger.warning(
            "jwt_validation_failed",
            extra={
                "event_type": "token_expired",
                "token_type": "Bearer",
                "jti": None,
                "iss": None,
                "aud": None,
                "scope": None,
                "error": "expired_token",
                "timestamp": time.time(),
            },
        )
        return None
    except jwt.InvalidTokenError as e:
        # Avoid logging the raw token; log token type and a truncated form if needed for debugging
        token_hint = token[:8] + "..." if len(token) > 12 else "invalid"
        logger.warning(
            "jwt_validation_failed",
            extra={
                "event_type": "invalid_token",
                "token_type": "Bearer",
                "jti": None,
                "iss": None,
                "aud": None,
                "scope": None,
                "error": str(e),
                "token_hint": token_hint,
                "timestamp": time.time(),
            },
        )
        return None

async def get_current_user(token: HTTPAuthorizationCredentials = Depends(security_scheme)):
    if not token.scheme == "Bearer":
        logger.warning(
            "auth_scheme_mismatch",
            extra={
                "event_type": "auth_scheme_mismatch",
                "token_scheme": token.scheme,
                "expected_scheme": "Bearer",
                "timestamp": time.time(),
            },
        )
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Unsupported authentication scheme",
        )

    payload = decode_token(token.credentials)
    if payload is None:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Invalid token",
        )

    # Log successful validation with non-sensitive metadata
    logger.info(
        "jwt_validation_success",
        extra={
            "event_type": "token_validated",
            "jti": payload.get("jti"),
            "iss": payload.get("iss"),
            "aud": payload.get("aud"),
            "scope": payload.get("scope"),
            "sub": payload.get("sub"),
            "exp": payload.get("exp"),
            "iat": payload.get("iat"),
            "timestamp": time.time(),
        },
    )

    return payload

Key remediation practices:

• Log token metadata (jti, iss, aud, exp, iat, scope) without logging the raw token or sensitive claims like PII.
• Explicitly log validation failures with distinct event types (token_expired, invalid_token, auth_scheme_mismatch) and include a token hint rather than the full token.
• Use structured logging with extra fields to enable correlation and filtering in SIEM systems.
• Ensure logs include timestamps and correlation identifiers so token usage can be traced across distributed services.
• Avoid logging stack traces or full request bodies that may contain tokens; instead rely on structured audit entries.

middleBrick’s LLM/AI Security and Data Exposure checks can further validate that logs do not inadvertently capture tokens and that audit fields are present, helping teams maintain secure observability for JWT-based APIs.