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