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

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 sso or passkey authentification, enable (from the admin) to bypass totp prompt to
users o have it

Why

A passkey is already two factors: something the person has, unlocked by something they are
or know. Asking for a TOTP code afterwards is a second lock on a door that already has one,
and that is the friction that makes people switch two-factor off altogether.

Single sign-on is the same argument at one remove. The identity provider has already done
the checking the instance is about to repeat, and on a company or university provider it
very often did it with something stronger than TOTP.

It has to be the operator's decision rather than each person's, because the operator is
the one who knows what their provider actually enforces.

Shape

Server settings → Sign-in gains two switches, both off by default:
- A passkey counts as the second factor. Somebody who signed in with a passkey is not
  asked for TOTP.
- Single sign-on counts as the second factor. Somebody who arrived through a configured
  provider is not asked either, under a plain sentence saying this trusts that provider's
  own checking.
An environment variable for each, so an operator who configures by file need not open a
page.
What it must not do: it never removes anybody's TOTP, and it never applies to a
password sign-in. Somebody who has TOTP and signs in with a password is asked for it,
always.
The account page says which of a person's ways in count as complete, so nobody has to
work out why they were asked once and not the next time.
Turning either on is worth recording: it lowers what the instance demands of everybody on
it, and an operator should be able to see when that changed.

Classification

Enhancement, and one that deliberately weakens a control — so it is off unless somebody
chooses it, and the page says what it costs. Not breaking.

Depends on

#47, for the passkey half. The SSO half works against what is already there.

Open questions

Per provider rather than one switch for all SSO? A university's provider and a personal
account at a large provider are not the same promise. Proposal: one switch now, per
provider when a second one exists.
Does MFA_TRUST_ENABLED stay as it is? Yes. A trusted device is a different bargain and
is already each person's own choice.

## Observation > for sso or passkey authentification, enable (from the admin) to bypass totp prompt to > users o have it ## Why A passkey is already two factors: something the person has, unlocked by something they are or know. Asking for a TOTP code afterwards is a second lock on a door that already has one, and that is the friction that makes people switch two-factor off altogether. Single sign-on is the same argument at one remove. The identity provider has already done the checking the instance is about to repeat, and on a company or university provider it very often did it with something stronger than TOTP. It has to be the **operator's** decision rather than each person's, because the operator is the one who knows what their provider actually enforces. ## Shape - ***Server settings → Sign-in*** gains two switches, both off by default: - *A passkey counts as the second factor.* Somebody who signed in with a passkey is not asked for TOTP. - *Single sign-on counts as the second factor.* Somebody who arrived through a configured provider is not asked either, under a plain sentence saying this trusts that provider's own checking. - An environment variable for each, so an operator who configures by file need not open a page. - **What it must not do**: it never removes anybody's TOTP, and it never applies to a password sign-in. Somebody who has TOTP and signs in with a password is asked for it, always. - The account page says which of a person's ways in count as complete, so nobody has to work out why they were asked once and not the next time. - Turning either on is worth recording: it lowers what the instance demands of everybody on it, and an operator should be able to see when that changed. ## Classification Enhancement, and one that deliberately weakens a control — so it is off unless somebody chooses it, and the page says what it costs. Not breaking. ## Depends on #47, for the passkey half. The SSO half works against what is already there. ## Open questions 1. Per provider rather than one switch for all SSO? A university's provider and a personal account at a large provider are not the same promise. Proposal: one switch now, per provider when a second one exists. 2. Does `MFA_TRUST_ENABLED` stay as it is? Yes. A trusted device is a different bargain and is already each person's own choice.

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 added a new dependency

2026-09-06 15:47:11 +00:00

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