菜单
Set up production-ready WebAuthn passkey authentication using webauthx. Use when adding passkey auth, WebAuthn registration, or WebAuthn authentication to an app.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/wevm/webauthx --skill webauthx命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | webauthx |
| description | Set up production-ready WebAuthn passkey authentication using webauthx. Use when adding passkey auth, WebAuthn registration, or WebAuthn authentication to an app. |
Set up production-ready WebAuthn passkey ceremony orchestration using webauthx.
Read README.md for the full API reference. Read examples/hono/ for a simplified reference implementation. The example prioritizes clarity over production hardening, so follow this checklist for production.
Install webauthx and import from webauthx/server and webauthx/client.
Registration.getOptions({ name, rp }). Returns { challenge, options }.challenge server-side (signed cookie, DB, or KV). Must be single-use and short-lived (≤5 min).options to Registration.create({ options }). Triggers the browser passkey prompt. Must be called from a user gesture (click/tap).Registration.verify(credential, { challenge, origin, rpId }).result.credential.id and result.credential.publicKey associated with the user.Authentication.getOptions({ credentialId, rpId }). Returns { challenge, options }.options to Authentication.sign({ options }). Must be user-initiated.publicKey by response.id, then call Authentication.verify(response, { challenge, publicKey, origin, rpId }).POST /register/options + POST /register/verify). Don't combine them into a single endpoint.HttpOnly, Secure, SameSite: 'Lax', and Path: '/' on both. Use signed cookies to prevent tampering.examples/hono/ for a reference pattern.Registration.create and Authentication.sign must be called from a click/tap handler. Browsers reject unprompted WebAuthn calls.credentialId, createdAt, lastUsedAt) and remove ones they don't recognize.rp.id stable. Changing your rpId invalidates all existing credentials. Pick it once.Follow every item below for production deployments.
localhost is the only exception).Strict-Transport-Security with includeSubDomains and preload.Cache-Control: no-store on all ceremony endpoints.origin and rpId on the server. Never accept them from the client or derive from request headers.rpId is a registrable domain (e.g. example.com), no scheme, no path. To share passkeys across subdomains, use the parent domain.origin must exactly match what the browser sends (e.g. https://app.example.com). For multiple origins, use a strict allowlist.registration vs authentication), the user, and the expected rpId/origin.If using cookies to store challenges (like the Hono example):
HttpOnly: true to prevent JavaScript access.Secure: true so it's only sent over HTTPS.SameSite: 'Lax' (or 'Strict' if UX allows).Path: '/' or scoped narrowly to ceremony endpoints.maxAge matching your challenge TTL.user.id must be a stable, opaque, non-PII identifier (raw bytes, ≤64 bytes). Don't use email or username directly as the user handle since this leaks PII to authenticators.user.id for the account across registrations.userVerification: 'required' for passkey-grade assurance. Don't rely on defaults since they may vary across libraries and spec versions.attestation: 'none' unless you have a specific business need for device provenance. Attestation validation is complex and easy to get wrong.excludeCredentialIds to prevent duplicate registration with the same authenticator.userVerification: 'required'.credentialId to scope the browser prompt. Account enumeration risk comes from whether the server reveals "user exists", so mitigate with generic responses and rate limiting.credentialId and map response.id to a user server-side.HttpOnly, Secure, SameSite, shortest acceptable TTL.Access-Control-Allow-Origin: * with credentials.SameSite cookies alone are not sufficient for cross-origin credentialed requests.Content-Security-Policy: frame-ancestors 'none' (or a strict allowlist) on pages that initiate ceremonies.Permissions-Policy: publickey-credentials-create=(self), publickey-credentials-get=(self) to restrict where WebAuthn can be called.Persist per credential (minimum):
credentialId: stable identifierpublicKey: hex-encoded P-256 public key from Registration.verifyuserId: associated user accountcreatedAt / lastUsedAt: for audit and UXOptional (not currently exposed by webauthx, use ox/webauthn directly if needed):
signCount: track and validate to detect cloned authenticatorstransports: for UX hints (USB, NFC, BLE, internal)backupEligible / backupState: for risk-scoring synced vs hardware-bound passkeys