Skip to main content
Identity Authority
Category: FIDO & Passkeys

Client Data JSON

Also known as: clientDataJSON
Simply put

Client Data JSON is a piece of information created by a user's browser or device during a WebAuthn passwordless or security-key login or registration. It records details about the specific sign-in attempt, such as what kind of action is taking place and which website is involved, so the server can confirm the request is genuine. This helps the website and the user's device agree on exactly what is being signed.

Formal definition

In the W3C WebAuthn specification, clientDataJSON is a JSON-compatible serialization of the collected client data assembled by the client (typically the browser or platform WebAuthn API) during a registration or authentication ceremony. It carries contextual fields describing the ceremony, including a type attribute that indicates whether the operation is a credential creation or an assertion, along with values used by the relying party to validate the ceremony. Per Source 1, the client computes a clientDataHash by hashing the clientDataJSON; per Source 5, implementations such as the Win32 WebAuthn API represent it as a UTF-8 encoded JSON serialization with an associated hash algorithm identifier. The authenticator signs over data that incorporates this hash rather than the raw clientDataJSON itself, which lets the relying party bind the returned signature to the specific ceremony context; note this is a signing/integrity mechanism and does not by itself imply encryption of the client data. This term is scoped to WebAuthn/FIDO2 ceremonies and is distinct from IGA or token-issuance artifacts; related variants such as the proposed remoteClientDataJSON extension (Source 4) address passing exact client data in remote-host scenarios and are out of scope for the core definition.

Why it matters

Client Data JSON is a foundational element of how WebAuthn binds a signature to a specific sign-in or registration attempt. Because the authenticator ultimately signs over a hash that incorporates this client data, the relying party can verify that the returned assertion corresponds to the exact ceremony context the client observed, including the type of operation being performed and other values used for validation. This binding is what allows a server to distinguish a genuine, in-context request from a replayed or mismatched one, making clientDataJSON central to the security properties that make passwordless and security-key authentication resistant to certain classes of attack.

For teams designing or auditing WebAuthn/FIDO2 deployments, understanding clientDataJSON matters because errors in how the relying party validates it can undermine the assurances of the entire ceremony. The relying party is responsible for checking the contextual fields carried in the client data against what it expects for the ceremony; skipping or weakening these checks can weaken the protection the protocol is designed to provide. It is also important to be precise about what this artifact does and does not do: the hashing and signing mechanism provides integrity binding, not confidentiality. Signing over the client data hash does not encrypt the client data, and treating it as if it did would be a misreading of the mechanism.

Finally, clientDataJSON is scoped specifically to WebAuthn ceremonies and should not be confused with token-issuance artifacts or identity governance data. It is a runtime authentication construct, not a provisioning or certification record. Keeping this scope clear helps architects reason accurately about where in an access flow the guarantees actually apply.

Who it's relevant to

IAM engineers and WebAuthn integrators
Engineers implementing WebAuthn/FIDO2 flows need to understand how the client produces clientDataJSON and how the relying party validates its contextual fields, including the type attribute distinguishing a creation from an assertion. Because the authenticator signs over a hash that incorporates this data rather than the raw JSON, correct relying-party validation is essential to preserving the ceremony's security guarantees.
Security architects designing passwordless authentication
Architects evaluating passwordless or security-key strategies benefit from understanding that clientDataJSON provides a binding between the returned signature and the specific ceremony context. This helps them reason accurately about the integrity properties WebAuthn offers, and about what it does not offer, since this mechanism is about signing and integrity, not encryption of the client data.
Platform and API developers
Developers working with platform interfaces such as the Win32 WebAuthn API encounter clientDataJSON as a UTF-8 encoded JSON serialization accompanied by a hash algorithm identifier. Understanding this representation, and related proposals such as the remoteClientDataJSON extension for remote-host scenarios, is useful when building or integrating WebAuthn support, though such variants are out of scope for the core concept.

Inside Client Data JSON

type
A string identifying the operation being performed, typically "webauthn.create" during registration (credential creation) or "webauthn.get" during authentication (assertion). Relying parties should verify this value matches the expected ceremony.
challenge
The base64url-encoded challenge that the relying party originally sent to the authenticator. The RP verifies it equals the challenge it issued, which is central to preventing replay attacks in the WebAuthn ceremony.
origin
The fully qualified origin (scheme, host, and port) of the requesting party as perceived by the client. The RP verifies this against its expected origin, which helps bind the ceremony to the intended web origin and mitigate phishing.
crossOrigin
An optional boolean indicating whether the call was made from a context in a cross-origin frame. Depending on RP policy, its presence or value may affect whether the ceremony is accepted.
tokenBinding (where applicable)
An optional member describing the token binding state for the connection over which the request was made, when token binding is supported. Support and use vary by client and deployment, and it is not universally present.

Common questions

Answers to the questions practitioners most commonly ask about Client Data JSON.

Is Client Data JSON the same as the authenticator data, or does it come from the authenticator?
No. Client Data JSON is assembled by the client (typically the browser or platform WebAuthn client), not by the authenticator. It represents the contextual data the client saw during the ceremony, such as the challenge, origin, and ceremony type. Authenticator data is a separate, distinct structure produced by the authenticator itself. Conflating the two is a common mistake; in WebAuthn assertion and attestation responses they are returned as separate fields and are validated separately by the relying party.
Does Client Data JSON authenticate the user by itself?
No. Client Data JSON is one input the relying party validates during a WebAuthn ceremony, but on its own it does not establish authentication. It carries data such as the challenge, origin, and type that the relying party checks, and its hash is signed together with authenticator data to produce the assertion signature. Authentication depends on verifying that signature against the registered credential and confirming the surrounding checks; the Client Data JSON contributes context but is not itself proof of who the principal is.
Which fields in Client Data JSON should a relying party verify during a ceremony?
In most WebAuthn deployments the relying party checks the type field to confirm the expected ceremony (typically webauthn.create for registration and webauthn.get for authentication), verifies that the challenge matches the one the server issued for this ceremony, and confirms that the origin matches an expected origin. Depending on configuration, additional fields such as crossOrigin or token binding information may also be evaluated. The exact set of checks can vary by profile and library, so consult the WebAuthn specification and your implementation for the authoritative list.
How is Client Data JSON used to produce and validate the signature?
During a ceremony the client computes a hash of the Client Data JSON, and in most implementations that hash is concatenated with the authenticator data and signed by the authenticator's private key. On the server side, the relying party independently hashes the received Client Data JSON, combines it with the authenticator data, and verifies the signature against the registered public key. Because the challenge is embedded in the Client Data JSON and covered by the signature, this binds the signed response to the specific ceremony and helps mitigate replay.
Why does the relying party need to compare the origin in Client Data JSON against an expected value?
Comparing the origin helps ensure the ceremony was performed against the intended relying party rather than a look-alike or attacker-controlled site, which supports WebAuthn's phishing-resistance properties. In most deployments the server maintains a set of acceptable origins and rejects responses whose origin does not match. Handling of subdomains, ports, or multiple valid origins depends on configuration and the relying party's policy, so the acceptable-origin logic should be defined explicitly rather than assumed.
How should Client Data JSON be parsed and compared reliably across clients?
Client Data JSON is transmitted as a byte sequence, and relying parties typically hash the exact bytes received rather than re-serializing a parsed object, since re-serialization can change the byte representation and break signature verification. For field-level checks such as type, challenge, and origin, the JSON is parsed to read those values, but the signature-relevant hash should be computed over the original bytes. Because encoding and field presence can vary by client, validation logic should rely on the received data and the WebAuthn specification rather than assumptions about a fixed layout.

Common misconceptions

The clientDataJSON is signed or encrypted by the authenticator to protect its confidentiality.
The clientDataJSON itself is not encrypted; its confidentiality is not the goal. Its integrity is protected because a hash of it is signed together with the authenticator data as part of the WebAuthn assertion or attestation. Signing establishes integrity and origin binding, which is distinct from encryption.
Client Data JSON is what proves the user's identity, so validating it alone authenticates the user.
Client Data JSON conveys ceremony context such as type, challenge, and origin, and is one input the relying party checks. Authentication in WebAuthn depends on verifying the authenticator's signature over the authenticator data and the clientDataJSON hash; the client data is a necessary but not sufficient part of that verification.
Because the browser produces the Client Data JSON, the relying party can trust its fields without checking them.
The relying party is expected to independently verify the type, challenge, and origin values against what it expects. These checks are what give the client data security value; accepting it without verification undermines the anti-replay and origin-binding protections.

Best practices

Always verify that the type field matches the expected ceremony ("webauthn.create" for registration, "webauthn.get" for authentication) before accepting the response.
Compare the challenge in the clientDataJSON against the exact challenge the relying party generated and stored for this ceremony, and reject any mismatch.
Validate the origin against the relying party's expected origin set, and apply an explicit policy for the crossOrigin indicator rather than ignoring it.
Verify integrity by computing the hash of the clientDataJSON and confirming the authenticator's signature covers that hash together with the authenticator data; do not treat receipt of the client data as proof by itself.
Do not rely on clientDataJSON for confidentiality, since it is not encrypted; avoid placing sensitive data in fields you expect to remain private.
Handle optional members such as tokenBinding defensively, accounting for clients that omit them, since their presence and support depend on the client and deployment configuration.
Promotional banner for the Pentest Readiness checklist download