Re: [oauth] SASL mechanisms - Mailing list pgsql-hackers

From Nico Williams
Subject Re: [oauth] SASL mechanisms
Date
Msg-id aWaaU51CP0fJXXDR@ubby
Whole thread Raw
In response to Re: [oauth] SASL mechanisms  (Jacob Champion <jacob.champion@enterprisedb.com>)
List 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
-- 



pgsql-hackers by date:

Previous
From: Mark Wong
Date:
Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD
Next
From: Robert Haas
Date:
Subject: Re: Enhancing Memory Context Statistics Reporting