Prompt and suitable context
The SaaS already supports passwords and is adding passkeys. A user may sign in from a phone, laptop, or hardware security key; some credentials may sync through a platform, while high-risk enterprise actions require stronger user verification. Design registration, authentication, recovery, migration, and observability.
The scope is WebAuthn and the server-verification boundary. Passkeys do not automatically solve session management, account recovery, device revocation, or business authorization.
What the interviewer evaluates
The interviewer checks whether you understand that the browser and authenticator hold the private key while the server stores the public key; each ceremony uses a one-time random challenge; and the verifier checks challenge, RP ID, origin, signature, and required user-presence or user-verification flags.
A strong answer also separates “phishing-resistant” from “never lost.” Syncable credentials improve availability but may not meet the strongest non-exportability requirements. If recovery bypasses an equivalent proof, the whole design is only as strong as its weakest path.
Clarifications to ask first
- Which actions require only sign-in, and which require UV or a device-bound credential?
- Does the RP ID cover multiple subdomains, and will WebAuthn run in a cross-origin iframe?
- May the enterprise prohibit syncable credentials or require hardware keys?
- Which existing factors remain for recovery, and can an operator review it?
- What is the migration and revocation timeline for passwords, TOTP, and passkeys?
A 30-second answer framework
“The server creates a one-time challenge for every registration or authentication and binds it to a session. After the ceremony it verifies RP ID, origin, challenge, signature, and required UP/UV flags. Registration stores the public key, credential ID, counter, and policy metadata, never the private key. I would tier syncable credentials by risk and require UV or device binding for sensitive actions. Recovery uses existing strong factors, a short-lived one-time flow, and risk review; SMS is not an unconditional back door.”
Step-by-step deep answer
Step 1: Define registration and authentication data
Before registration, the server creates an unpredictable, short-lived, single-use challenge and stores it in a session or one-time store. The client calls navigator.credentials.create(); the authenticator creates a key pair and returns a public-key credential.
Store the credential ID, public key, account, RP ID, signature counter, backup eligibility, and backup state as needed. The private key remains in the authenticator or platform credential manager.
Step 2: Perform strict authentication checks
For sign-in, the server creates a fresh challenge and publicKeyCredentialRequestOptions; the client calls navigator.credentials.get(). Verify:
const valid = await verifyAuthenticationResponse({
response,
expectedChallenge: session.challenge,
expectedOrigin: "https://app.example.com",
expectedRPID: "app.example.com",
requireUserVerification: true
});Consume the challenge immediately after successful verification. Reject replayed, expired, or cross-session responses, then verify the signature with the stored public key. Also handle cancellation, unsupported browsers, and temporarily unavailable authenticators.
Step 3: Understand RP IDs, origins, and cross-origin risk
The RP ID identifies the relying party for a credential; a credential cannot authenticate to a different RP ID. The server must also check the calling origin rather than comparing only a registrable domain. A cross-origin iframe or Related Origin Request needs an explicit review of whether the user knows who is requesting the ceremony and a separate compatibility test.
A company logo is not origin proof. Origin, RP ID, challenge, and signature must be verified together across the browser/authenticator context and the server.
Step 4: Reason about UP, UV, and sync state by risk
UP means the user interacted with the authenticator; UV means the authenticator locally verified the user. Ordinary sign-in can choose a policy by risk, while transfers, key export, and administrator actions should require UV and have the server inspect the returned flag.
Syncable credentials improve cross-device availability, but NIST notes that syncing involves key exportability. Whether that meets an assurance level depends on the deployment policy. Record backup eligibility and state; do not call “syncable” “already synced” or “device-bound.”
Step 5: Design recovery, migration, and revocation
When a user loses a device, prefer another registered passkey, an enterprise recovery key, or a reviewed strong-identity flow. A recovery token must be short-lived, single-use, session-bound, and revocable. After recovery, notify the user, rotate sessions, and let the user review and remove old credentials.
During password migration, keep a controlled transition period and reduce password reliance after a passkey is created; do not silently delete every old factor in the same request. Each credential needs independent revocation state, while anomalous counters, risky devices, and recovery events enter the audit stream.
High-quality sample answer
“I would start by tiering the security goals. The server creates a one-time challenge for every registration and authentication and stores it in a short-lived session. It verifies challenge, RP ID, origin, signature, and the UP/UV flags required by that action, then consumes the challenge. The database stores public key, credential ID, counter, account, and backup state; the private key never leaves the authenticator.
I would not enable cross-origin iframe use by default. If required, I would put caller origin, top-level origin, and RP ID in the test matrix. Ordinary sign-in can accept policy-compliant syncable credentials, while sensitive actions require UV or device binding. Recovery prefers another strong passkey or enterprise recovery key, with one-time expiry, risk controls, and notification. SMS can be an explicitly accepted fallback, never a permanent way around strong authentication. Production telemetry watches challenge replay, origin mismatch, missing UV, recovery success, and anomalous revocations.”
Common mistakes
- Verify only the signature → a valid signature does not prove the right challenge, RP ID, or origin → check each field and consume the challenge.
- Treat UP as UV → touching an authenticator is not local user verification → require and inspect UV for high-risk actions.
- Call a syncable passkey device-bound → sync eligibility and actual sync are different facts → record backup flags and decide by assurance level.
- Recover with an SMS link immediately → the weakest path can take over the account → use strong existing factors, short-lived tokens, risk review, and notification.
- Check only the registrable domain → an origin includes scheme, host, and port → compare the normalized full origin.
- Reuse challenges → an intercepted assertion can be replayed → make challenges random, short-lived, single-use, and session-bound.
Follow-up questions and responses
Follow-up 1: Why are passkeys phishing-resistant?
The authenticator selects credentials based on origin and RP ID and signs the server challenge with its context. A phishing site cannot obtain a valid proof for the real service from the authenticator. The server must still verify origin, RP ID, and challenge.
Follow-up 2: Why not keep the challenge only on the client?
The server must know the random value it issued to connect the response to the current login intent and reject replay. A client-generated or separately stored value does not prove that the server initiated this ceremony.
Follow-up 3: Are syncable credentials inherently unsafe?
Avoid a binary claim. Sync improves recovery and cross-device usability, while exportability, provider policy, and organizational assurance requirements differ. The server should inspect backup flags by risk tier and require stronger factors for sensitive actions.
Follow-up 4: What if the user loses every device?
Treat recovery as high-risk authentication: use an enterprise recovery key, another reviewed strong factor, or an operator review, with limited scope and time, notification, and revocation of unknown credentials. Convenience must not permanently lower the login assurance level.