Re: [PoC] Federated Authn/z with OAUTHBEARER

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Antonin Houska <ah@cybertec.at>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-01-09T22:44:34Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. meson: Fix install-quiet after clean

  2. oauth: Run Autoconf tests with correct compiler flags

  3. Link libpq with libdl if the platform needs that.

  4. Doc: correct spelling of meson switch.

  5. oauth: Correct SSL dependency for libpq-oauth.a

  6. oauth: Fix Autoconf build on macOS

  7. oauth: Move the builtin flow into a separate module

  8. Remove a stray "pgrminclude" annotation

  9. oauth: Simplify copy of PGoauthBearerRequest

  10. oauth: Improve validator docs on interruptibility

  11. oauth: Disallow synchronous DNS in libcurl

  12. oauth: Fix postcondition for set_timer on macOS

  13. oauth: Use IPv4-only issuer in oauth_validator tests

  14. Work around OAuth/EVFILT_TIMER quirk on NetBSD.

  15. oauth: Fix incorrect const markers in struct

  16. Add missing entry to oauth_validator test .gitignore

  17. cirrus: Temporarily fix libcurl link error

  18. Add support for OAUTHBEARER SASL mechanism

  19. libpq: Handle asynchronous actions during SASL

  20. require_auth: prepare for multiple SASL mechanisms

  21. Move PG_MAX_AUTH_TOKEN_LENGTH to libpq/auth.h

  22. Make SASL max message length configurable

  23. jsonapi: fully initialize dummy lexer

  24. common/jsonapi: support libpq as a client

  25. Remove fe_memutils from libpgcommon_shlib

  26. Revert ECPG's use of pnstrdup()

  27. Explicitly require password for SCRAM exchange

  28. Refactor SASL exchange to return tri-state status

> On 9 Jan 2025, at 23:35, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
> 
> On Thu, Jan 9, 2025 at 12:40 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>> + * Find the start of the .well-known prefix. IETF rules state this must be
>> + * at the beginning of the path component, but OIDC defined it at the end
>> + * instead, so we have to search for it anywhere.
>> I was looking for a reference for OIDC defining the WK prefix placement but I
>> could only find it deferring to RFC5785 like how RFC8414 does.  Can you inject
>> a document reference for this?
> 
> I'll add a note in the comment. It's in Section 4 of OIDC Discovery
> 1.0: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
> 
> (This references RFC 5785, but only to obliquely point out that it's
> not actually compliant with RFC 5785, if the issuer ID has a path
> component. Section 4.1 gives an example.)

Thanks!

>> + if (strcmp(conn->oauth_issuer_id, discovery_issuer) != 0)
>> Shouldn't the scheme component really be compared case-insensitive, or has it
>> been normalized at this point?  Not sure how much it matters in practice but if
>> not perhaps we should add a TODO marker there?
> 
> I don't think we should. While I've read some fights about the meaning
> of "identical" in OIDCD Sec 4.3, IETF seems to be pushing hard for
> exact equality of issuer IDs. RFC 9207 says [1]
> 
>   This [issuer] comparison MUST use simple string comparison as
> defined in Section 6.2.1 of [RFC3986].
> 
> (Simple string comparison being byte/character-wise rather than
> performing a normalization step.) While RFC 9207 doesn't govern the
> Device Authorization flow yet (maybe not ever?), the current OAuth 2.1
> draft refers to its rules as a MUST [2], and I think we should just be
> strict for the safety of future flow implementations.
> 
> I'm sure someone's going to complain at some point, but IMNSHO, the
> fix for them is just to use the same formatting and capitalization as
> the discovery document, and move on.

Fair enough, I buy that. Maybe the above could be de-opinionated slightly and added as a comment to help others reading the code down the line?

--
Daniel Gustafsson