JWT implementation flaws in Quarkus (SmallRye JWT) are a goldmine for bypasses. Most vulnerabilities stem from 'alg: none' acceptance, weak HMAC secrets, or key confusion attacks. If your configuration is loose, an attacker can forge tokens to escalate privileges. As a Senior AppSec researcher, my goal is to harden the identity layer by enforcing strict cryptographic boundaries and moving away from shared secrets.

The Vulnerable Pattern

# application.properties - CRITICAL VULNERABILITIES
# 1. Allowing None algorithm or missing signature verification
smallrye.jwt.verify.relax-key-validation=true
2. Using a weak symmetric secret (vulnerable to brute force/dictionary attacks)
mp.jwt.verify.publickey=my-secret-key-123
smallrye.jwt.verify.algorithm=HS256
3. No issuer or audience validation
(Allows tokens from untrusted providers)

The Secure Implementation

The fix involves three pillars: Algorithm Enforcement, Key Strength, and Claim Validation. First, explicitly setting 'smallrye.jwt.verify.algorithm' to RS256 or ES256 prevents 'alg: none' downgrade attacks and HMAC key confusion where a public key is treated as a symmetric secret. Second, we move secrets out of the config and use a JWKS endpoint or a PEM-encoded public key, ensuring the application never handles the private signing key. Finally, enforcing 'issuer' and 'audiences' prevents token redirection attacks where a valid token for 'Service B' is used to gain unauthorized access to 'Service A'.

# application.properties - HARDENED CONFIGURATION
# 1. Enforce Asymmetric Signing (RS256/ES256)
smallrye.jwt.verify.publickey.location=https://auth.internal.corp/jwks
smallrye.jwt.verify.algorithm=RS256
2. Mandatory Claims Validation
mp.jwt.verify.issuer=https://auth.internal.corp
smallrye.jwt.verify.audiences=api-service-alpha
3. Disable validation relaxation
smallrye.jwt.verify.relax-key-validation=false
Ensure clock skew is tight
smallrye.jwt.expiration.grace-period=30