Re: [oauth] SASL mechanisms
| От | Nico Williams |
|---|---|
| Тема | Re: [oauth] SASL mechanisms |
| Дата | |
| Msg-id | aWaaU51CP0fJXXDR@ubby обсуждение исходный текст |
| Ответ на | Re: [oauth] SASL mechanisms (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Ответы |
Re: [oauth] SASL mechanisms
|
| Список | 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 по дате отправления: