Fix Broken User Authentication in Micronaut

Micronaut's security defaults are robust, but developer negligence often results in 'Broken Authentication'—specifically through weak JWT implementations. Hardcoded secrets, lack of signature verification, and overly long token lifetimes allow attackers to forge identities and escalate privileges. This guide addresses securing the JWT lifecycle within the Micronaut framework.

The Vulnerable Pattern

micronaut:
  security:
    authentication: jwt
    token:
      jwt:
        signatures:
          secret:
            generator:
              secret: "my-weak-secret-123" # CRITICAL: Hardcoded and low entropy
              jwe: false
        generator:
          access-token:
            expiration: 86400 # 24 hours is too long for high-risk apps

The Secure Implementation

The vulnerability stems from using a hardcoded, low-entropy secret key. Attackers can perform offline brute-force attacks against the JWT signature to recover the key and forge administrative tokens. The secure implementation mandates the use of environment-injected secrets (ensuring high entropy and preventing source code leaks) and significantly reduces the 'expiration' window to limit the blast radius of a compromised token. For production, migrating to RS256 (asymmetric) with JWKS is the recommended standard to ensure the signing key never leaves the identity provider.

micronaut:
  security:
    authentication: jwt
    token:
      jwt:
        signatures:
          secret:
            validation:
              # Use high-entropy keys injected via environment variables
              secret: ${JWT_SIGNING_KEY}
        generator:
          access-token:
            expiration: 900 # 15 minutes max
    intercept-url-map:
      - pattern: "/**"
        access:
          - isAuthenticated()
    # Enforce HTTPS to prevent token interception
    redirect: 
      prior-to-login: true