| From: | Nico Williams <nico(at)cryptonector(dot)com> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Subject: | Re: [oauth] SASL mechanisms |
| Date: | 2026-01-13 19:17:39 |
| Message-ID: | aWaaU51CP0fJXXDR@ubby |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Dec 09, 2025 at 01:18:43PM -0800, Jacob Champion wrote:
> [...]
What do you think of
https://datatracker.ietf.org/doc/id/draft-williams-http-bearer-extension.txt
?
Yes, it's HTTP-specific, but somee of that might be useful here.
Also, what do you think of a GSS-API mechanism that supports JWT for
client auth? I've a design in mind where if you ask for no security
services in gss_init_sec_context()'s req_flags then you get a singular
context token and it's just the JWT, and otherwise you get TLS 1.3
handshake messages as GSS tokens w/ ALPN to identify this as a GSS mech
and the JWT as 0-rtt data or piggybacked (encrypteed either way) onto
the client final, w/ TLS exporter for keying Kerberos per-message
tokens. This would allow PG to support JWT via GSS-API. Look ma'! no
changes!
On the client/initiator side I'd have the client fetch a token as needed
from the local, configured STS, and do something like Kerberos referrals
(HTTP redirects) for "cross-realm" stuff if needed.
Nico
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-01-13 19:31:00 | Re: Enhancing Memory Context Statistics Reporting |
| Previous Message | Mark Wong | 2026-01-13 19:12:33 | Re: Speed up COPY FROM text/CSV parsing using SIMD |