justauth/JustAuth · error · AuthException

Unsupported algorithm: ${algorithm}

Error message

Unsupported algorithm: ${algorithm}

What it means

Internal guard in GlobalAuthUtils.sign: Mac.getInstance(algorithm) threw NoSuchAlgorithmException, meaning the JVM has no provider offering the requested MAC algorithm. In stock JDKs the algorithms JustAuth requests (HmacSHA1/HmacSHA256 for signature building in Douyin/Twitter-style flows) always exist, so this error almost always indicates a stripped or custom runtime, or corrupted algorithm-name plumbing. Unlike the numbered AuthResponseStatus errors, this AuthException carries only the message 'Unsupported algorithm: <name>'.

Source

Thrown at src/main/java/me/zhyd/oauth/utils/GlobalAuthUtils.java:55

        byte[] signData = sign(secretKey.getBytes(DEFAULT_ENCODING), timestamp.getBytes(DEFAULT_ENCODING), HMAC_SHA_256);
        return urlEncode(new String(Base64Utils.encode(signData, false)));
    }

    /**
     * 签名
     *
     * @param key       key
     * @param data      data
     * @param algorithm algorithm
     * @return byte[]
     */
    private static byte[] sign(byte[] key, byte[] data, String algorithm) {
        try {
            Mac mac = Mac.getInstance(algorithm);
            mac.init(new SecretKeySpec(key, algorithm));
            return mac.doFinal(data);
        } catch (NoSuchAlgorithmException ex) {
            throw new AuthException("Unsupported algorithm: " + algorithm, ex);
        } catch (InvalidKeyException ex) {
            throw new AuthException("Invalid key: " + Arrays.toString(key), ex);
        }
    }

    /**
     * 编码
     *
     * @param value str
     * @return encode str
     */
    public static String urlEncode(String value) {
        if (value == null) {
            return "";
        }
        try {
            String encoded = URLEncoder.encode(value, GlobalAuthUtils.DEFAULT_ENCODING.displayName());
            return encoded.replace("+", "%20").replace("*", "%2A").replace("~", "%7E").replace("/", "%2F");

View on GitHub (pinned to 694bbf1b01)

Solutions

  1. Identify the algorithm from the message and confirm it is available: run a tiny main() that calls javax.crypto.Mac.getInstance(algorithm) on the same runtime.
  2. Switch to a full JDK/JRE image (e.g. eclipse-temurin instead of a minimal variant) or add the missing provider/JDK module to the image.
  3. Audit java.security / security provider config for entries that removed or reordered Mac providers.
  4. If a custom provider is required, register it before first JustAuth use.

Example fix

// diagnostics: run on the failing runtime
Mac mac = Mac.getInstance("HmacSHA256"); // throws here => runtime lacks the algorithm
// fix: use a full JDK base image
// before: FROM alpine-jre-stripped
// after:  FROM eclipse-temurin:21-jre
Defensive patterns

Strategy: try-catch

Validate before calling

try { javax.crypto.Mac.getInstance("HmacSHA256"); }
catch (NoSuchAlgorithmException e) { throw new IllegalStateException("JVM lacks HmacSHA256 — use a full JDK image"); }

Try / catch

catch (AuthException e) { if (e.getMessage() != null && e.getMessage().startsWith("Unsupported algorithm:")) { /* runtime/crypto-provider problem — fix JVM, do not retry */ } }

Prevention

When it happens

Trigger: Running on a trimmed JRE (jlink runtime without jdk.crypto.ec / MAC services), an unusual JVM, or a security manager/provider setup where the HmacSHA* implementation was removed; theoretically also a future call site passing an unsupported algorithm string. Thrown while building signed request URLs (e.g. generate DingTalk/Douyin style signatures).

Common situations: Docker images based on minimal/alpine JREs that stripped crypto modules; custom Security.provider lists in java.security overriding defaults; FIPS-enabled runtimes restricting MAC algorithms; upgrading to a distro Java build with reduced crypto.

Related errors


AI-assisted analysis of justauth/JustAuth@694bbf1b01 (2026-08-14). Data as JSON: /api/errors/1d314cecdcf364e7. Report an issue: GitHub.