jwtk/jjwt · error · UnsupportedOperationException
Not intended to be called.
Error message
Not intended to be called.
What it means
An UnsupportedOperationException stating 'Not intended to be called.' thrown from the anonymous Password KeyResult's getDecryptionKey method. This is an internal invariant guard: the PBES2 wrapper implements getEncryptionKey only, and decryption keys are resolved through a different path, so calling this method means the library internals were invoked incorrectly.
Source
Thrown at impl/src/main/java/io/jsonwebtoken/impl/security/StandardKeyAlgorithms.java:100
// ensure that the bare minimum steps are performed to hash, ensuring our time sampling pertains only to
// hashing and not ancillary steps needed to setup the hashing/derivation
return new KeyAlgorithm<Password, Password>() {
@Override
public KeyResult getEncryptionKey(KeyRequest<Password> request) throws SecurityException {
int iterations = request.getHeader().getPbes2Count();
char[] password = request.getKey().getPassword();
try {
alg.deriveKey(factory, password, rfcSalt, iterations);
} catch (Exception e) {
throw new SecurityException("Unable to derive key", e);
}
return null;
}
@Override
public SecretKey getDecryptionKey(DecryptionKeyRequest<Password> request) throws SecurityException {
throw new UnsupportedOperationException("Not intended to be called.");
}
@Override
public String getId() {
return alg.getId();
}
};
}
private static char randomChar() {
return (char) Randoms.secureRandom().nextInt(Character.MAX_VALUE);
}
private static char[] randomChars(@SuppressWarnings("SameParameterValue") int length) {
char[] chars = new char[length];
for (int i = 0; i < length; i++) {
chars[i] = randomChar();
}View on GitHub (pinned to fb71496164)
Solutions
- Do not call getDecryptionKey on the KeyResult of a password (PBES2) algorithm; use the parser's decryptWith(password) API instead.
- If writing a custom KeyAlgorithm, implement decryption via the DecryptionKeyRequest path your own class provides.
- If hit during normal use, report it as a jjwt bug including the stack trace and version.
- Ensure all jjwt artifacts (api/impl/jackson) are the same version.
Example fix
// before SecretKey key = passwordKeyResult.getDecryptionKey(request); // UnsupportedOperationException // after SecretKey key = Jwts.KEY.get(password, StandardKeyAlgorithms.PBES2_HS256_A128KW.getId()); // proper API path // or simply: Jwts.parser().decryptWith(password)
Defensive patterns
Strategy: type-guard
Prevention
- Use only public jjwt APIs (Jwts.parser().decryptWith) instead of impl internals
- Never call getDecryptionKey on PBES2 KeyResults
- Pin all jjwt artifact versions together
- If implementing a custom KeyAlgorithm, implement both directions via the proper request types
When it happens
Trigger: Only when internal code or a custom KeyAlgorithm extension calls getDecryptionKey on the password-based KeyResult returned by StandardKeyAlgorithms for encryption; normal user code never triggers it.
Common situations: Almost exclusively hit by library contributors or by custom crypto implementations that reuse StandardKeyAlgorithms results in unsupported ways; possibly after a jjwt version upgrade mixing mismatched impl classes.
Related errors
- ${getName()} instance is immutable and may not be modified.
- Unexpected unsecured Claims JWT.
- Unexpected content JWS.
- Unexpected Claims JWS.
- Unexpected content JWE.
AI-assisted analysis of jwtk/jjwt@fb71496164 (2026-09-09).
Data as JSON: /api/errors/e9cd7d56e83a29ad.
Report an issue: GitHub.