Re: Time to add FIDO2 support?

On Fri, Jan 23, 2026, at 18:19, Zsolt Parragi wrote:
>> Would others be interested in adding support for FIDO2 as a new SASL
>> authentication mechanism?
>
> Me definitely, I was also thinking about the same thing. For context,
> I did implement fido authentication for Percona Server for MySQL.

Cool, what a match!

> But as far as I know, SASL only has drafts[1][2] about fido, not accepted RFCs.

Thanks for the links; I hadn't seen either of these.

Draft [1] ("SASL Passkey") is essentially "SASL over WebAuthn/passkeys".
I don't think the browser-based WebAuthn-protocol maps well to PostgreSQL,
due to the browser-specific RP ID model (DNS name, HTTPS, origin checks,
etc). Also, for Passkeys i.e. Cloud Provider backed keys, to work,
at least on Apple macOS, native apps need platform-specific entitlement
/ domain-association requirements (AASA).

[2] proposes SCRAM-2FA, that extends SCRAM with TOTP and FIDO U2F/CTAP1
support. This is the older FIDO protocol, not FIDO2/CTAP2. U2F
requires the server to store and provide the credential ID during auth.
FIDO2 supports "resident keys" stored on the device, which is nice,
since otherwise the server must leak what credentials exist for a user,
or mix it up with fake ones. Not sure if it's a typo, but there is a note
that says "Should we pick between TOTP and FIDO2 (CTAP1)?", but FIDO2
is CTAP2.

> This is also related to why I asked about generic (not oauth related)
> authentication plugins on the list a few days ago[3], one of the
> things I was thinking about was fido/webauthn.

Is the idea with [3] to allow proposing new auth mechanism that
have not been standarized as SASL mechanisms?

Since none of the existing SASL drafts seem to fit our needs,
how about we try to standardize on a new SASL mechanism?

Very rough sketch:

1. client-first-message (65 bytes): ES256 public key
The client sends its 65-byte uncompressed EC public key (0x04 || x || y)
to identify which credential it wants to authenticate with.

2. server-challenge (34 bytes): version(1) + challenge(32) + options(1)
The server looks up the public key in a new pg_role_pubkeys table,
generates a 32-byte random challenge, and sends it back with protocol
version and option flags (user presence required, user verification
required).

3. client-assertion (69 bytes): flags(1) + counter(4) + signature(64)
The client signs the challenge using the authenticator and returns
the authenticator flags, signature counter, and raw ECDSA signature
(r || s, each 32 bytes).

Server verifies the signature using the stored public key, and (optionally)
checks/signals counter rollback.

The client uses the OpenSSH sk-provider API (sk_sign,
sk_load_resident_keys) to interact with the authenticator, which is the
same API that OpenSSH uses. This means any sk-provider library that
works with OpenSSH (such as the macOS ssh-keychain.dylib or
Yubikey's libfido2) will also work.

>> Add "fido2" to pg_hba.conf:
>>
>> hostssl all all 0.0.0.0/0 fido2
>> hostssl all all ::/0 fido2
>
> It would be really good to implement MFA properly (allowing users to
> configure password + fido requirement for login), but that would also
> require changes in pg_hba processing.

If the idea is to add pg_hba.conf support to specify requirement
of password + [some other method], that sounds like an excellent idea!

> [1] : https://www.ietf.org/archive/id/draft-bucksch-sasl-passkey-00.html
> [2] :
> https://www.ietf.org/archive/id/draft-ietf-kitten-scram-2fa-05.html
> [3] :
> https://www.postgresql.org/message-id/CAN4CZFN%3D5%3DdWvY%3DYAPeF4PVOMtR5U6jMLc2kCSHdO0EhejPp%2BQ%40mail.gmail.com