Frontend interview: Can WebAuthn largeBlob replace server-side user state?

Prompt and scope

The product wants to bind a small encrypted configuration to a user's WebAuthn credential to reduce server-side state. Explain when largeBlob fits, how registration and authentication differ, how the client checks results, and how login and data correctness survive unsupported devices.

What interviewer is testing

• Whether you know largeBlob is opaque data associated with one credential, not general client storage.
• Whether you distinguish registration support from authentication read and write inputs and outputs.
• Whether you account for authenticator capacity, discoverable credentials, and the one-credential write constraint.
• Whether you design capability detection, server backup, privacy, and failure fallback.

Clarifying questions

1. Must the data travel with this credential, or are a server database and IndexedDB sufficient?
2. What are the size, confidentiality, recoverability, and cross-device requirements?
3. Does the target authenticator support largeBlob, and is the credential discoverable?
4. How does the system recover after a failed write, lost credential, or device change?

A 30-second answer

I would treat largeBlob as an optional authenticator capability, not primary storage. During registration request support: preferred and inspect supported; during authentication use either read or write, target exactly one credential for a write, and check blob or written. Encrypt and bound the data and keep a recoverable server copy. Unsupported capability, capacity, or write failure should fall back to server state without blocking login or treating an unconfirmed write as successful.

Step-by-step design

1. Choose the right data boundary

The specification defines largeBlob as opaque data associated with a credential. It fits small credential-bound configuration or key material, not user profiles, cross-credential synchronization, or an object database. Authenticators have limited capacity, so the server should retain recovery information.

2. Use registration only for capability detection

The registration extension accepts largeBlob: { support: "preferred" } or required. supported says whether the created credential can store a blob; registration does not write one. With required, unsupported authenticators are excluded, so measure the compatibility cost before making it mandatory.

3. Separate reads and writes during authentication

Authentication can request read: true or provide write; supplying both fails. A write requires allowCredentials to contain exactly one credential, and success is reported by written. A blob member is present only after a successful read, not merely because the extension object exists.

4. Design privacy, recovery, and fallback

Authenticator data is opaque, not automatically application-encrypted. The client and server should provide encryption, versioning, and integrity checks. If the credential is unavailable, the device lacks support, capacity is insufficient, or the user declines, use the server copy. Log capability and outcome, never blob contents.

Model high-quality answer

I would not use largeBlob as a replacement for server-side state. It is useful for binding a small opaque value to one WebAuthn credential. During registration I would request support: preferred and inspect supported; during authentication I would choose read or write, target one credential for a write, and check blob or written. The application owns encryption, versioning, and integrity, while the server keeps a recoverable copy. Unsupported authenticators, discoverable-credential constraints, capacity errors, write failures, and device changes all fall back to server state without blocking authentication. I would require the feature only when the product accepts reduced compatibility and has a migration plan. This uses authenticator storage without making login or recovery depend on it.

Common mistakes

• Treating largeBlob as IndexedDB, a cookie, or unlimited cloud-synchronized storage.
• Assuming a blob can be written during registration.
• Supplying read and write together or naming multiple credentials for a write.
• Checking only that the extension object exists instead of supported, blob, or written.
• Writing sensitive data into an opaque blob without application encryption.
• Blocking login when an authenticator lacks support instead of falling back to the server.

Follow-up questions and responses

How do you choose preferred versus required?

preferred permits an unsupported authenticator and a fallback; required excludes it. Prefer preferred unless the product accepts lower coverage and truly depends on the capability.

Why must a write target exactly one credential?

The specification uses a single allowCredentials target to identify the credential being updated. Multiple candidates produce an unsupported-operation failure, so the application must resolve the user's credential first.

What is the device-migration plan?

Treat the blob as an optional cache or key copy and keep recovery material on the server. A new device obtains server state through re-registration or authentication; do not assume the authenticator blob synchronizes across devices.