apache/hadoop · error · AuthenticationException

Invalid AuthenticationToken type

Error message

Invalid AuthenticationToken type

What it means

After parsing a valid, correctly signed hadoop.auth cookie, AuthenticationFilter.getToken calls verifyTokenType to check that the token's type matches one of the types the configured AuthenticationHandler supports (matters for CompositeAuthenticationHandler, which accepts several; and for anonymous/pseudo 'a' tokens). A mismatch throws AuthenticationException('Invalid AuthenticationToken type'): the signature is fine, but the cookie was issued under a different authentication scheme than the one now active.

Source

Thrown at hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationFilter.java:451

        if (cookie.getName().equals(AuthenticatedURL.AUTH_COOKIE)) {
          tokenStr = cookie.getValue();
          if (tokenStr.isEmpty()) {
            throw new AuthenticationException("Unauthorized access");
          }
          try {
            tokenStr = signer.verifyAndExtract(tokenStr);
          } catch (SignerException ex) {
            throw new AuthenticationException(ex);
          }
          break;
        }
      }
    }
    if (tokenStr != null) {
      token = AuthenticationToken.parse(tokenStr);
      boolean match = verifyTokenType(getAuthenticationHandler(), token);
      if (!match) {
        throw new AuthenticationException("Invalid AuthenticationToken type");
      }
      if (token.isExpired()) {
        throw new AuthenticationException("AuthenticationToken expired");
      }
    }
    return token;
  }

  /**
   * This method verifies if the specified token type matches one of the the
   * token types supported by a specified {@link AuthenticationHandler}. This
   * method is specifically designed to work with
   * {@link CompositeAuthenticationHandler} implementation which supports
   * multiple authentication schemes while the {@link AuthenticationHandler}
   * interface supports a single type via
   * {@linkplain AuthenticationHandler#getType()} method.
   *
   * @param handler The authentication handler whose supported token types

View on GitHub (pinned to 2add963021)

Solutions

1. Have clients re-authenticate (clear the hadoop.auth cookie or open a fresh session) to obtain a token of the new type.
2. When changing authentication.type, rotate the signing secret (signature.secret.file / random) so stale cookies are rejected as invalid signatures rather than type-mismatched.
3. For CompositeAuthenticationHandler, confirm the token types it advertises include every scheme clients actually use.
4. Verify all server nodes share the same handler configuration so type checks agree across the fleet.

// server-side tooling: ensure handler advertises the token type you issue
AuthenticationHandler h = getAuthenticationHandler();
Set<String> accepted = new HashSet<>(Collections.singletonList(h.getType()));
// for composite handlers, add AuthenticationHandlerUtil.getAuthenticationHandlerTypes(h)
if (!accepted.contains(expectedTokenType)) { failConfig("handler cannot accept token type " + expectedTokenType); }

try {
  new AuthenticatedURL().openConnection(url, token);
} catch (AuthenticationException e) {
  if ("Invalid AuthenticationToken type".equals(e.getMessage())) {
    token = new AuthenticatedURL.Token(); // old-scheme cookie: re-authenticate under current type
    authenticator.authenticate(url, token);
  } else { throw e; }
}

When it happens

Trigger: Server switched authentication.type (e.g. kerberos -> simple, or handler set changed) while the signing secret stayed the same, so old cookies still verify but their type (e.g. 'kerberos' or anonymous 'a') is no longer accepted; composite handler whose type list does not include the token's type; a pseudo-issued token presented to a kerberos-only handler.

Common situations: Rolling back or changing auth configuration on a cluster without rotating the signing secret; staging and production sharing a secret file; composite handlers (e.g. kerberos+token) configured inconsistently across nodes; long-lived browser cookies surviving an auth-type migration.

Understand the failure class

• Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.

Related errors

• Authentication failed, URL: {}, status: {}, message: {}
• AuthenticationToken expired
• tokenStr cannot be null
• url cannot be NULL
• url must be for a HTTP or HTTPS resource

AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/95845b9ffd4a605e. Report an issue: GitHub.