WebAuthn/FIDO2 Login Fails with "Invalid client JSON parameters" (Error 2001006)

Products

• Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Issue/Introduction

When a relying-party (RP) application submits a WebAuthn assertion (login) to AuthHub for verification, the request may be rejected with the following error:

{
  "errorCode": "2001006",
  "errorMessage": "Invalid client JSON parameters"
}

HTTP status returned: 401 Unauthorized

This error occurs during FIDO2 assertion verification, before AuthHub attempts to validate the authenticator's signature. Users attempting to sign in with a security key, platform authenticator (Windows Hello, Touch ID, etc.), or passkey will see their login attempt fail.

Environment

AgentMinder Identity formally known as Identity Security Platform ( IDSP) 

Version 4.0.4

Cause

AuthHub requires the clientDataJSON field inside the response object of the assertion payload to be present and non-empty:

{
  "id": "...",
  "rawId": "...",
  "type": "public-key",
  "response": {
    "authenticatorData": "...",
    "signature": "...",
    "clientDataJSON": "..."   <-- must be a non-empty, base64url-encoded string
  }
}

This error is returned whenever response.clientDataJSON is missing, null, or an empty/blank string in the request sent to AuthHub. Per the WebAuthn specification (https://www.w3.org/TR/webauthn-2/), the browser's navigator.credentials.get() call always returns a populated clientDataJSON ArrayBuffer on AuthenticatorAssertionResponse — so an empty value reaching AuthHub indicates the value was lost, dropped, or never encoded correctly somewhere in the RP application's client-side integration code before the request was sent.

Common root causes on the integrating application's side:
- credential.response.clientDataJSON (an ArrayBuffer) was not base64url-encoded before being placed into the JSON request body.
- The field was renamed, omitted, or nested incorrectly when constructing the payload (e.g., placed at the top level instead of inside response).
- A custom serialization/transform step (polyfill, wrapper SDK, mobile bridge) stripped the field.
- An intermediary proxy, API gateway, or WAF in front of the RP application altered or truncated the POST body before it reached AuthHub.

Resolution

• Capture the exact request payload your application sends to /factor/v1/FIDOAuthChallengeVerifier for a failing login attempt and confirm whether response.clientDataJSON is present and non-empty.
• Verify client-side encoding. Ensure your WebAuthn integration correctly base64url-encodes the ArrayBuffer values returned by the browser before sending them to AuthHub.
• If you're using a third-party WebAuthn client library, check that it hasn't silently failed to populate this field (e.g., due to an unsupported browser/authenticator combination).
• Check for intermediary interference. If your application sits behind a reverse proxy, API gateway, or WAF, confirm the raw POST body isn't being modified, re-serialized, or truncated in transit.
• Retry with a supported browser/authenticator. If the issue is intermittent and isolated to specific browsers or platform authenticators, confirm the client environment is on a current, WebAuthn Level 2–compliant browser version.