Wrap WebAuthn library errors and log their category server-side - #4326
Closed
KaveeshaPiumini wants to merge 1 commit into
Closed
Wrap WebAuthn library errors and log their category server-side#4326KaveeshaPiumini wants to merge 1 commit into
KaveeshaPiumini wants to merge 1 commit into
Conversation
Contributor
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Keep library-specific details from reaching external clients while making verification failures debuggable server-side. The passkey service already returned generic internal error codes to clients for WebAuthn verification failures. This adds structured server-side logging of the underlying go-webauthn error category via a small webAuthnErrorFields helper: when the library error is a protocol.Error, its type, detail and debug info are logged as separate fields (including through wrapped errors), otherwise the plain message is logged. Clients continue to receive only the generic internal codes, so no library detail is exposed. - Add webAuthnErrorFields in webauthn_service.go, the layer that abstracts the WebAuthn library, keeping library-specific knowledge in one place. - Use it at the CreateCredential, ValidateLogin and ValidatePasskeyLogin failure sites, which return the existing generic PSK codes. - Add unit tests for the helper. Fixes thunder-id#1647 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
KaveeshaPiumini
force-pushed
the
fix/1647-wrap-webauthn-errors
branch
from
July 25, 2026 09:24
bc4ac08 to
e06d090
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Keep library-specific details generated by the underlying
go-webauthnlibrary from reaching external clients, while making WebAuthn verification failures debuggable server-side. Refs #1647.The passkey service already returned generic internal
PSKcodes to clients for verification failures (no library string ever reached a client). What was missing was structured, debuggable server-side detail about why the library rejected a ceremony.Approach
webAuthnErrorFields(err)helper inwebauthn_service.go(the layer that already abstracts the WebAuthn library, so library-specific knowledge stays in one place). When the error is aprotocol.Errorit logs the category, detail and debug info as separate fields (recognized through wrapped errors viaerrors.As); otherwise it logs the plain message.CreateCredential,ValidateLogin,ValidatePasskeyLogin), which continue to return the existing genericPSKcodes to clients.Why not a per-category error taxonomy? An earlier revision mapped each library error category to a distinct client-facing code. That was dropped deliberately: exposing exactly why an authentication ceremony failed (challenge vs. signature vs. origin) is a verification oracle, and hardened WebAuthn implementations return a single generic failure to the client with the specifics kept in server logs. This revision does exactly that, with far less code and no new API surface.
Evidence (local)
Real registration verification failure (origin mismatch fixture):
The caller receives generic
PSK-1011(invalid attestation response); no library detail is exposed. All passkey/authn/flow tests pass,golangci-lintreports 0 issues, i18n catalog unchanged from baseline.Related Issues
Checklist
webauthn_error_fields_test.go; existingservice_test.gocovers real library failures returning generic codes)Security checks
🤖 Generated with Claude Code