Re: Time to add FIDO2 support?

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: Joel Jacobson <joel(at)compiler(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Time to add FIDO2 support?
Date: 2026-01-27 11:10:56
Message-ID: CAN4CZFPZt0aBu0v7ZQ2bnYjkokat64c3odQ-aiygYgRYehpA=A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-01-27 11:32:57 logical apply worker's lock waits in subscriber can stall checkpointer in publisher
Previous Message Dilip Kumar 2026-01-27 11:10:55 Re: unnecessary executor overheads around seqscans