Passkeys, so signing in needs no password at all #47

New issue

Closed

opened 2026-09-06 15:46:45 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-06 15:46:45 +00:00

Owner

Observation

for native authentification i would like to enable passkeys

What exists today

Signing in is a password, and optionally TOTP with recovery codes:
MFA_SUPPORTED_TYPES = ["totp", "recovery_codes"] in config/settings/base.py, with
MFA_TRUST_ENABLED for a thirty-day trusted device.
The dependency is django-allauth[mfa] 65.19, and that extra already brings fido2.
The installed version supports WebAuthn, so this is configuration, templates, words
and tests rather than new protocol code.

Shape

Add "webauthn" to MFA_SUPPORTED_TYPES, and turn on MFA_PASSKEY_LOGIN_ENABLED so a
passkey is a way in rather than only a second factor. MFA_PASSKEY_SIGNUP_ENABLED
stays off: an instance decides who may register (#3), and a passkey at sign-up does not
change that decision.
Settings → Account gains Passkeys: add one, name it, see when each was last used,
remove one. Removing the last passkey from an account with no password is refused, for
the same reason the last administrator cannot be deleted.
A passkey is bound to WEBAUTHN_RP_ID, the instance's hostname. An instance reached
at two names, or moved to a new one, invalidates every passkey on it. The settings page
and Configuration both have to say so plainly rather than leaving somebody locked out
of their own record.
HTTPS is required by the browser API, localhost excepted. The page says so rather
than failing silently on an instance served over plain HTTP.
Recovery codes matter more once a passkey can be the only way in: the flow that adds a
first passkey should offer them, not mention them.

Classification

Enhancement. Not breaking: passwords keep working, and an instance that turns nothing on
behaves exactly as it does today.

Depends on

Nothing. #48 depends on this.

Open questions

May an account be password-less — a passkey and nothing else? Proposal: yes, once
recovery codes exist.
Does a passkey count as the second factor on its own? Yes, and that is #48.

## Observation > for native authentification i would like to enable passkeys ## What exists today - Signing in is a password, and optionally TOTP with recovery codes: `MFA_SUPPORTED_TYPES = ["totp", "recovery_codes"]` in `config/settings/base.py`, with `MFA_TRUST_ENABLED` for a thirty-day trusted device. - The dependency is `django-allauth[mfa]` 65.19, and that extra already brings `fido2`. **The installed version supports WebAuthn**, so this is configuration, templates, words and tests rather than new protocol code. ## Shape - Add `"webauthn"` to `MFA_SUPPORTED_TYPES`, and turn on `MFA_PASSKEY_LOGIN_ENABLED` so a passkey is a way *in* rather than only a second factor. `MFA_PASSKEY_SIGNUP_ENABLED` stays off: an instance decides who may register (#3), and a passkey at sign-up does not change that decision. - ***Settings → Account* gains *Passkeys***: add one, name it, see when each was last used, remove one. Removing the last passkey from an account with no password is refused, for the same reason the last administrator cannot be deleted. - **A passkey is bound to `WEBAUTHN_RP_ID`, the instance's hostname.** An instance reached at two names, or moved to a new one, invalidates every passkey on it. The settings page and *Configuration* both have to say so plainly rather than leaving somebody locked out of their own record. - **HTTPS is required** by the browser API, `localhost` excepted. The page says so rather than failing silently on an instance served over plain HTTP. - Recovery codes matter more once a passkey can be the only way in: the flow that adds a first passkey should offer them, not mention them. ## Classification Enhancement. Not breaking: passwords keep working, and an instance that turns nothing on behaves exactly as it does today. ## Depends on Nothing. #48 depends on this. ## Open questions 1. May an account be password-less — a passkey and nothing else? Proposal: yes, once recovery codes exist. 2. Does a passkey count as the second factor on its own? Yes, and that is #48.

tiagoagueda added this to the 0.2.0 milestone

2026-09-06 15:46:45 +00:00

tiagoagueda added the

labels

2026-09-06 15:46:45 +00:00

tiagoagueda referenced this issue

2026-09-06 15:46:46 +00:00

Let an administrator waive the second factor for a passkey or an SSO sign-in #48