Passkeys 1: schema, dependency, and per-environment RP configuration #37

New Issue

2026-08-17T17:14:01-05:00

bermudalamb commented

2026-08-17 17:14:01 -05:00

Part of the Passkeys project. Parent: #36.

Groundwork only — no user-visible behavior. Everything else in the project builds on this.

Scope

Add @simplewebauthn/server (backend) and @simplewebauthn/browser (frontend)
Migration for credential storage: credential ID, public key, signature counter, transports, owning customer, created/last-used timestamps
Migration for in-flight challenges, which must be single-use and expiring
Relying Party configuration derived from the environment

Why RP configuration is the interesting part

The Relying Party ID is a domain, and a credential is bound to it permanently. That means:

Environment	RP ID	Consequence
Local	`localhost`	Works — `http://localhost` is a secure context
QA	`qa-redefined-designs.bermudalamb.synology.me`	Passkeys registered here work only here
Production	`redefined-designs.bermudalamb.synology.me`	Separate credentials again

So QA can prove the flow but never the credentials. This needs deriving from PUBLIC_URL, which every environment already sets, rather than being hardcoded.

Decisions to make

Signature counter handling: reject on a counter regression, or log and continue? (Some authenticators do not increment reliably.)
Challenge storage: a table, or reuse customer_tokens with a new kind?
Whether credentials survive an account being disabled (#33) or deleted

Part of the Passkeys project. Parent: #36. Groundwork only — no user-visible behavior. Everything else in the project builds on this. ## Scope - Add `@simplewebauthn/server` (backend) and `@simplewebauthn/browser` (frontend) - Migration for credential storage: credential ID, public key, signature counter, transports, owning customer, created/last-used timestamps - Migration for in-flight challenges, which must be single-use and expiring - Relying Party configuration derived from the environment ## Why RP configuration is the interesting part The Relying Party ID is a domain, and a credential is bound to it permanently. That means: | Environment | RP ID | Consequence | | --- | --- | --- | | Local | `localhost` | Works — `http://localhost` is a secure context | | QA | `qa-redefined-designs.bermudalamb.synology.me` | Passkeys registered here work only here | | Production | `redefined-designs.bermudalamb.synology.me` | Separate credentials again | So QA can prove the *flow* but never the *credentials*. This needs deriving from `PUBLIC_URL`, which every environment already sets, rather than being hardcoded. ## Decisions to make - Signature counter handling: reject on a counter regression, or log and continue? (Some authenticators do not increment reliably.) - Challenge storage: a table, or reuse `customer_tokens` with a new `kind`? - Whether credentials survive an account being disabled (#33) or deleted

bermudalamb referenced this issue

2026-08-17 17:16:07 -05:00

Passkey (WebAuthn) login for customers #36

bermudalamb added this to the Passkey Implementation project 2026-08-17 17:21:29 -05:00

bermudalamb self-assigned this 2026-08-17 17:21:32 -05:00

bermudalamb referenced this issue from a commit

2026-09-09 13:48:12 -05:00

feat(passkeys): schema, dependency and per-environment Relying Party (#37)

bermudalamb referenced a pull request that will close this issue

2026-09-09 13:48:33 -05:00

feat(passkeys): schema, dependency and per-environment Relying Party (#37) #330

bermudalamb closed this issue