Passkeys: optional settings to let a passkey satisfy AAL2 and stand in for the current password

[DruidChiron]

Summary

With the new passkey support in Supabase Auth, a session established by signing in with a passkey is aal1 (AMR passkey), the same assurance level as a password sign-in. That is a sensible, conservative default. But there is currently no way for a project to choose otherwise, which has two consequences:

1. A user with a TOTP factor who signs in with a passkey is still asked for their TOTP code for anything that requires AAL2 (e.g. updateUser password change, managing passkeys while MFA is enabled).
2. With "Require current password when updating" enabled, a passkey cannot be used to re-authenticate. Only the current password is accepted, so a passkey-first user must keep a password solely to prove who they are when changing credentials.

Observed behaviour

Local Supabase CLI stack, supabase_flutter 2.18, Chrome on Windows 11, user with a verified TOTP factor and a registered passkey:

• Sign in with the passkey → auth.sessions.aal = 'aal1', mfa_amr_claims.authentication_method = 'passkey'.
• updateUser({ password }) → refused with insufficient_aal until a TOTP challenge is completed.
• Changing the password therefore takes three steps: passkey sign-in, current password, TOTP code.

Why this should be configurable rather than fixed

Whether a passkey deserves AAL2 depends on the passkey and on the project's risk profile:

• A passkey asserted with user verification (UV flag) combines possession of a private key with a biometric or device PIN, and it is phishing-resistant (origin-bound). In many contexts it can reasonably be treated as AAL2; NIST SP 800-63B and its 2024 supplement on syncable authenticators allow this under conditions.
• But a synced passkey's security also depends on the sync provider's account and recovery process, and on every device it syncs to. A device-bound passkey depends on that one device's platform. Some projects will reasonably want to treat one, both or neither as a second factor.
• WebAuthn already exposes what is needed to decide: the UV flag, and the backup eligibility/backup state flags (BE/BS), which tell a relying party whether a credential is syncable or has been synced.

Secure by default: passkeys should stay aal1 unless a project explicitly opts in.

Proposal

1. AAL setting, default off: "Passkeys can satisfy AAL2", with options such as never (today's behaviour), device-bound passkeys with user verification only (UV=1, BS=0), or any passkey with user verification.
2. Re-authentication setting, default off: allow a fresh passkey assertion (bound to the update request via a challenge) to satisfy "Require current password when updating", as an alternative to current_password. Recovery sessions keep their existing exemption.
3. Step-up: allow an existing aal1 session to step up with a passkey assertion, the way mfa.challenge/mfa.verify works for TOTP, without a full sign-out and sign-in (subject to setting 1).
4. Expose the flags: include UV/BE/BS (or a derived "synced"/"device-bound" field) in the passkey list, so apps can show users which kind they have. Today users usually can't tell; for example, the Windows prompt doesn't say whether a passkey is stored only on the device or synced.

Impact today

Applications that want admin actions protected by a second factor must either (a) ask passkey users for a TOTP code anyway, or (b) read the AMR claim themselves and treat passkey as a second factor in their own RLS, which then disagrees with Auth's own aal. We currently do (b) for our own policies and still hit (a) wherever Auth enforces AAL2 itself, such as password updates.

Happy to provide more detail or test a preview.

[DruidChiron]

Additional context: with passkeys counting toward AAL2 (or treated as a second factor by apps, as we do via the passkey AMR), there's a binding gap. Today a password-only aal1 session can register a user's first passkey (step-up only applies once a verified TOTP exists). That means the password alone can mint a credential that later satisfies a "second factor" check. If this enhancement is adopted, it would help to also have an option to require AAL2 or an existing-factor ceremony for all passkey registrations, including the first, or at least to expose on the session/AMR whether the passkey used was registered from an AAL2 session. Our workaround in the meantime is to require a TOTP for admin-tier accounts.