jwtk/jjwt · error · io.jsonwebtoken.UnsupportedJwtException

Unsupported ${id} ${algType} algorithm... is disabled (no ${

Error message

Unsupported ${id} ${algType} algorithm... is disabled (no ${algType} algorithms have been configured).

What it means

IdLocator resolved an algorithm identifier from the token (e.g. the alg header) but no algorithms of that type have been configured on the parser, so the algorithm is 'disabled'. It wraps the underlying lookup/verification failure in UnsupportedJwtException. This is a deliberate guard so tokens using algorithm families the application never enabled are rejected.

Source

Thrown at impl/src/main/java/io/jsonwebtoken/impl/IdLocator.java:76

        try {
            return registry.forKey(id);
        } catch (Exception e) {
            StringBuilder sb = new StringBuilder("Unsupported ")
                    .append(DefaultHeader.nameOf(header))
                    .append(" ")
                    .append(this.param)
                    .append(" value '").append(id).append("'");
            if (this.registry.isEmpty()) {
                sb.append(": ")
                        .append(this.behavior)
                        .append(" is disabled (no ")
                        .append(this.algType)
                        .append(" algorithms have been configured)");
            }
            sb.append(".");
            String msg = sb.toString();
            throw new UnsupportedJwtException(msg, e);
        }
    }

    @Override
    public R apply(H header) {
        return locate(header);
    }
}

View on GitHub (pinned to fb71496164)

Solutions

Configure the missing algorithm family on the parser (e.g. verifyWith the appropriate key type or extend the keyLocator registry)
Re-issue tokens using only the enabled algorithm families
If the algorithm should stay disabled, catch UnsupportedJwtException and reject the token explicitly

Example fix

// before
JwtParser parser = Jwts.parser().verifyWith(hmacKey).build(); // token uses RS256
// after
JwtParser parser = Jwts.parser().verifyWith(rsaPublicKey).build();

Defensive patterns

Strategy: try-catch

Validate before calling

String alg = parsed.getHeader("alg");
Set<String> enabled = Set.of("HS256", "RS256");
if (alg == null || !enabled.contains(alg)) throw new UnsupportedJwtException("alg not enabled: " + alg);

Try / catch

try {
    Jws<Claims> jws = parser.parseClaimsJws(token);
} catch (UnsupportedJwtException e) {
    respond(401, "Token algorithm is not accepted by this service");
}

Prevention

Keep the parser's configured algorithm families in sync with what the issuer signs
Explicitly whitelist algorithms and update the whitelist during key-rotation migrations
Reject unknown algorithms early with a clear 401 rather than a 500

When it happens

Trigger: Parsing a token whose alg header names an algorithm family (e.g. 'RS256' or 'dir') while the builder configured no algorithms of that algType (no verifyWith RSA keys, no key locators for that family, etc.).

Common situations: An issuer rotates from HMAC to RSA signing (or vice versa) but the consumer's parser only configures the old family; tightening security by whitelisting algorithms and receiving old tokens signed with now-disabled ones; asymmetric configuration between services.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of jwtk/jjwt@fb71496164 (2026-09-09). Data as JSON: /api/errors/a008343f6919d0cd. Report an issue: GitHub.