Обсуждение: Time to add FIDO2 support?
Hi hackers, Would others be interested in adding support for FIDO2 as a new SASL authentication mechanism? As a macOS user, FIDO2 has become very convenient since the release of macOS Tahoe in September 2025, that added built-in support for Secure Enclave-backed SSH keys [1] [2]. The key pair is generated on the Security Enclave and the private key cannot be exported, so even if your computer is compromised, you can be quite confident that they at least couldn't steal your private keys. When logging in, you have to touch the TouchID for the Security Enclave to sign the challenge. I really love how this scores very high on both security and convenience. So, I think it would be nice if authenticating to PostgreSQL via psql could be made equally secure and convenient, by simply reusing the same OpenSSH hardware-backed FIDO2 SSH keys, copying the key string from ~/.ssh/authorized_keys, and register it with your PostgreSQL role. This would of course also work with hardware keys, such as Yubikey. Example: ALTER ROLE joel ADD CREDENTIAL macos 'sk-ecdsa-sha2-nistp256@openssh.com AAAAInNrLWVjZHNhLXNoYTItbmlzdHAyNTZAb3BlbnNzaC5jb20AAAAIbmlzdHAyNTYAAABBBOG0NTN8AqegdlKrGTuddOFt0G4ANYzwkBtjSS0zCWCB1IuJisW41qBQ/JSGWjJp1B7OXD52AwfyB4sbUs1Kqg0AAAAEc3NoOg=='; Add "fido2" to pg_hba.conf: hostssl all all 0.0.0.0/0 fido2 hostssl all all ::/0 fido2 You would need to load the resident keys from the FIDO2 authenticator, once per bootup: % ssh-add -K Enter PIN for authenticator: Resident identity added: ECDSA-SK SHA256:6/FvVcfzjLTt27bieSk5UpsPFYvGGkL5njORDz1JmM8 You would then specify the sk-provider when connecting via psql: % PGSKPROVIDER=/usr/lib/ssh-keychain.dylib psql The server sends a random challenge, the user is prompted to touch the TouchID, the client's security key then signs it, and the server verifies the signature. I have some experience of FIDO2/WebAuthn in the application layer, and would be willing to try to draft a patch on this, given there is enough interest in this. /Joel [1] https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb4acf [2] https://lists.mindrot.org/pipermail/openssh-unix-dev/2024-July/041451.html
> 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. But as far as I know, SASL only has drafts[1][2] about fido, not accepted RFCs. 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. > 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. [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
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
On Tue, Jan 27, 2026, at 10:35, Joel Jacobson wrote:
> 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).
I was curious what would happen if trying a self-compiled Chromium
on my macOS machine, with a website that supports Passkeys.
Expectedly, it refuses access to the keys stored locally:
[35826:18100134:0127/105844.098344:ERROR:components/device_event_log/device_event_log_impl.cc:202] [10:58:44.058] FIDO:
touch_id_context.mm:89Touch ID authenticator unavailable because keychain-access-group entitlement is missing or
incorrect.Expected value: .org.chromium.Chromium.webauthn
This is due to the lack of "entitlement" for the app (Chromium).
However, when trying to sign-up and sign-in via Passkey, Chromium or
macOS instead shows a QR-code. Scanning this QR code with my separate
iPhone device, then opened up the native Apple Passkey UI, where I could
select among my passkeys, and then authenticate using FaceID.
While not as convenient as being able to use TouchID one the same
device, I still think this is interesting, as it would then provide an
option to use real cloud-backed Passkeys.
I haven't explored what kind of API that provides this QR-based Passkey
mechanism, but will do some digging. I guess psql would then
show a ASCII art QR code, which the user would scan using their
Cloud Provider mobile phone device.
If it turns out it could work, then I think it should be a separate auth
method, since it has different tradeoffs between security and
convenience, compared to only storing the secret key on the hardware
security device.
/Joel
> Is the idea with [3] to allow proposing new auth mechanism that > have not been standarized as SASL mechanisms? I think that would be useful from several perspectives: * New auth mechanisms could be used on earlier major versions without manual backporting in forks * It would allow quicker iterations/demos for new auth methods * Some auth methods are standardized, but have very special use cases - does it make sense to include them in the core? * And then we have things without any proper standardization, like fido For fido specifically, since there is no finalized standard, an extension could be a better fit than including something non-standard (if we want to stay within SASL, and not something completely custom). > Since none of the existing SASL drafts seem to fit our needs, > how about we try to standardize on a new SASL mechanism? That is a possibility, and maybe we should do that, but that will also take time. I just wanted to point out that there's no generally accepted way to implement this with SASL, we only have some earlier drafts. MySQL for example simply went with a custom protocol. > If the idea is to add pg_hba.conf support to specify requirement > of password + [some other method], that sounds like an excellent idea! Yes, I think that's a relatively common use case for these devices, so it would be nice to support it. On the other hand, that would be a separate feature for postgres authentication. I just wanted to mention it as that would increase the usefulness of a fido auth method. The other thing I forgot to mention in my previous mail is that I think fido would really benefit from a client selectable auth method - again not strictly part of it or a requirement, but the current "the first matching line wins" approach will result in some not so user friendly situations with it. For me, these 3 mean that I see fido more as a long term goal, its usefulness with the current authentication flow will be limited. Even with that, I am interested in a patch implementing it, and I don't want to go completely off topic in this thread with these other things, I just think that all these are closely related.