Re: [oauth] SASL mechanisms

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

In response to

Responses

Browse pgsql-hackers by date

  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