mirror of
https://github.com/we-promise/sure.git
synced 2026-09-02 21:31:07 +00:00
Guillem Arias Fauste
344cf091e1
* feat(auth): sign in with a passkey, without a password Passkeys could only ever replace the TOTP code: registration required 2FA to already be on, and the WebAuthn ceremony was reachable only after User.authenticate_by had succeeded. A registered passkey can now complete sign-in on its own, from the login page. The ceremony requests userVerification: "required", so the authenticator has to confirm the person as well as the device. That makes a lone passkey two independent factors, the same bar as the password plus TOTP flow it replaces, which is why this path deliberately skips the TOTP step. A credential that can only prove presence is rejected here and still works as a second factor. Sign-in is usernameless: no email is submitted, because the browser returns the account handle with the assertion. Nothing on this path can be probed to learn whether an account exists. Registration now asks for a discoverable credential with residentKey: "preferred" so the key is offered by the picker, while authenticators without a free resident-key slot still register as a second factor. Where conditional mediation is available, saved passkeys appear in the email field's autofill menu; everywhere else the button covers it. The automatic challenge request that conditional mediation makes on every page load gets its own looser Rack::Attack budget, so ordinary page views can no longer exhaust the limit that protects the MFA endpoints. Set AUTH_PASSKEY_LOGIN_ENABLED=false to keep passkeys as a second factor only. Passkey sign-in follows the same policy as local login, so it stays closed to regular users when AUTH_LOCAL_LOGIN_ENABLED is false. * refactor(auth): group the passkey button with the other sign-in methods It sat directly under the password fields, so the forgot-password link split it from the identical SSO buttons. It is an alternative to the credential form rather than part of it. * fix(auth): close the passkey challenge races and document the upgrade Three review passes converged on the conditional-mediation flow. The AbortController was created after `isConditionalMediationAvailable()` resolved, so a button click or a Turbo disconnect landing in that window found nothing to abort: the conditional task carried on, re-minted the challenge, and the assertion the user was about to produce verified against a challenge the server had already replaced. It is created before the first await now, and held in a local, because `abortConditionalMediation()` nulls the field. Checking that one signal after each await covers both triggers, so no separate connected flag is needed. The same symptom had a second cause nobody flagged: `authenticate()` was not re-entrant. A double-click minted a fresh challenge under an open authenticator prompt and rejected a perfectly valid passkey, with no race window at all — and it was live on the MFA step-up too, which shares the method. The conditional catch was silent for every failure, including a rejected assertion the user had deliberately chosen from the autofill menu. Splitting the try draws the line where it belongs: silence before the user has been asked anything, feedback once they have picked a passkey. Filtering on `error.name` cannot draw it, since `fetchOptions` and `verifyCredential` both raise a plain Error. Also documents the upgrade: passwordless is on by default and applies to already-registered credentials, so a passkey added purely as a second factor can now sign its owner in alone. Nothing in the schema marks a credential discoverable — the authenticator decides — and the opt-out is instance-wide. The invitation test is a guard, not coverage for this change. The pending token lives in the Rack session and `complete_sign_in` reads it right after creating the session, so a `reset_session` dropped in between strands the invitee in their own family, silently and with every existing test still green. * fix(auth): cancel the in-flight conditional options request Aborting the conditional flow did not cancel its options request, because `fetchOptions` never received the signal. A click landing while that POST was in flight left it to finish, and its response could apply last. The challenge rides in the session cookie, so "the server wrote it" only counts if the Set-Cookie reaches the browser. Threading the signal means an aborted request's response is discarded, which closes the window without needing the server to hold two challenges open. Also drops the absolute claim about which existing credentials gain passwordless sign-in. `residentKey: "preferred"` is a request an authenticator may decline, and nothing records what it decided, so the honest statement is that password managers and platform authenticators generally store discoverable credentials rather than always.
81 lines
4.8 KiB
Markdown
81 lines
4.8 KiB
Markdown
# WebAuthn Configuration
|
|
|
|
Sure supports passkeys, Touch ID, Windows Hello, and hardware security keys, both as a second factor and for passwordless sign-in. WebAuthn credentials are bound to the relying party ID used when they are registered, so production deployments should pin these values explicitly instead of deriving them from incoming request headers.
|
|
|
|
Set these environment variables for self-hosted deployments:
|
|
|
|
```bash
|
|
WEBAUTHN_RP_ID=example.com
|
|
WEBAUTHN_ALLOWED_ORIGINS=https://sure.example.com
|
|
```
|
|
|
|
`WEBAUTHN_RP_ID` is usually the registrable domain, such as `example.com`, not a full URL and not a hostname with a port. This lets credentials work across subdomains when the browser permits it.
|
|
|
|
`WEBAUTHN_ALLOWED_ORIGINS` is a comma-separated list of full origins where users access Sure, including scheme and host. Examples:
|
|
|
|
```bash
|
|
WEBAUTHN_ALLOWED_ORIGINS=https://sure.example.com,https://app.example.com
|
|
```
|
|
|
|
For local development, use:
|
|
|
|
```bash
|
|
WEBAUTHN_RP_ID=localhost
|
|
WEBAUTHN_ALLOWED_ORIGINS=http://localhost:3000
|
|
```
|
|
|
|
Changing `WEBAUTHN_RP_ID` after users register credentials can make existing passkeys and security keys unavailable. Keep the value stable across reverse proxy, domain, and hostname changes.
|
|
|
|
## Passwordless sign-in
|
|
|
|
A registered passkey can sign a user in directly from the login page, without a password and without the TOTP step. This is enabled by default:
|
|
|
|
```bash
|
|
AUTH_PASSKEY_LOGIN_ENABLED=true
|
|
```
|
|
|
|
Set it to `false` to keep passkeys as a second factor only.
|
|
|
|
### Why skipping the password is not a downgrade
|
|
|
|
The passwordless ceremony always requests `userVerification: "required"`, so the authenticator must confirm the person as well as the device — a biometric, a device PIN, or a security key PIN. That makes a lone passkey two independent factors (possession plus inherence or knowledge), which is the same bar as the password plus TOTP flow it replaces. An authenticator that can only confirm presence, such as a bare touch, is rejected on this path and still works as a second factor.
|
|
|
|
Sign-in is "usernameless": no email is submitted, because the browser returns the account handle along with the assertion. Nothing on this path can be probed to discover whether an account exists.
|
|
|
|
### Requirements
|
|
|
|
- The passkey must be **discoverable** (also called a resident key). Registration asks for one with `residentKey: "preferred"`. Password managers and platform authenticators — Proton Pass, iCloud Keychain, 1Password, Bitwarden, Windows Hello — store discoverable credentials by default. A hardware security key with no free resident-key slots still registers, but only as a second factor, and will not appear in the passkey picker.
|
|
- Users must enable two-factor authentication before they can register a passkey. Disabling 2FA removes every registered passkey, which also removes passwordless sign-in for that user.
|
|
- Passkey sign-in follows the same policy as local login. When `AUTH_LOCAL_LOGIN_ENABLED=false`, only super admins with `AUTH_LOCAL_ADMIN_OVERRIDE_ENABLED=true` may use it.
|
|
|
|
### Upgrading an instance that already has passkeys
|
|
|
|
Passwordless sign-in is on by default, and it applies to passkeys that were
|
|
registered before this feature existed. A passkey a user added purely as a
|
|
second factor can, after the upgrade, sign that user in on its own.
|
|
|
|
This applies to a credential only if the authenticator that holds it made it
|
|
discoverable. Registration asks with `residentKey: "preferred"`, which an
|
|
authenticator is free to decline, and nothing in the database records what it
|
|
decided — so Sure cannot tell you in advance which existing credentials are
|
|
affected. In practice password managers and platform authenticators (Proton
|
|
Pass, iCloud Keychain, 1Password, Bitwarden, Windows Hello) store discoverable
|
|
credentials by default, so theirs generally are; a credential an authenticator
|
|
stored non-discoverably, such as one on a hardware key with no free resident-key
|
|
slot, stays second-factor only. Nothing needs to be re-registered either way.
|
|
|
|
The opt-out is instance-wide. There is no per-user or per-credential setting: to
|
|
keep passkeys as a second factor for everyone, set
|
|
`AUTH_PASSKEY_LOGIN_ENABLED=false` before upgrading. A single user can only opt
|
|
out by removing the credential.
|
|
|
|
This is not a reduction in security — the passwordless ceremony requires user
|
|
verification, so the passkey alone is still two factors, as described above. It
|
|
is a change in what an already-registered credential can do, and users who chose
|
|
a passkey specifically as a *second* factor have not consented to it signing
|
|
them in alone.
|
|
|
|
### Browser autofill
|
|
|
|
When the browser supports conditional mediation, saved passkeys are offered from the email field's autofill menu, before any button is clicked. Browsers without it fall back to the "Sign in with a passkey" button, which works the same way.
|