MIME-Version: 1.0
References: <Z-qheTno9lYmjrJu@msg.df7cb.de>
 <CAOYmi+=mGJfJUdz13Ty86-epEX4g9zRNVq0+i+KmHsodAJ2FdQ@mail.gmail.com>
 <Z_YsaLBiv9LfUM-e@msg.df7cb.de>
 <CAOYmi+nQapg91WVfb06uL02UEisPBejQd4sOC3G77aKqsnE7KQ@mail.gmail.com>
 <Z_ayCLeAEinXvSxL@msg.df7cb.de>
 <CAOYmi+n9DHS_xUatuuspdC8tjtaMzY8P11Y9y5Fz+2pjikkL9g@mail.gmail.com>
 <CAGECzQS7R4VKcpdDb0-qDpxPMCFB+3yPy+aPKNNYJyMKg4Omyg@mail.gmail.com>
 <CAOYmi+nQRtnvFCdjRx+rA=MS1XTB8JTzj0q2o+zitzw=DSCYWg@mail.gmail.com>
 <487dacec-6d8d-46c0-a36f-d5b8c81a56f1@technowledgy.de>
 <CAOYmi+kxyFxkdj6gfRTJhTKEQtK_bh0qTBTRb3nWsPfhrME7WA@mail.gmail.com>
 <012b6a4a-aead-411a-a9db-c6c7b25e1dcc@technowledgy.de>
 <ee4560d0-4997-485a-a628-66890f35ae8c@technowledgy.de>
 <CAOYmi+mmp0CJfLGdQf9LF647063Hhcoz-bBZ4AhMFVx8ZL9tOA@mail.gmail.com>
 <3ef2e077-396c-4953-b062-c28fe16d2749@technowledgy.de>
 <CAOYmi+nt1CxgXJC8+D2SpuM=ydPvKKkUbhnvcBay_pnqdpThQQ@mail.gmail.com>
 <CAOYmi+=pFfkDFpRMXE87x73ee-viTgn6ztE_VkxnYE7owr_SbQ@mail.gmail.com>
 <227ce390-b604-4b1b-924a-1540729d8e3a@tantorlabs.com>
In-Reply-To: <227ce390-b604-4b1b-924a-1540729d8e3a@tantorlabs.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Mon, 21 Apr 2025 09:57:33 -0700
Message-ID: 
 <CAOYmi+mnmzUXm8rUXU=SO5NtXjUtYT=aJWrALB4ZNow5eo49jg@mail.gmail.com>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
To: Ivan Kush <ivan.kush@tantorlabs.com>
Cc: Wolfgang Walther <walther@technowledgy.de>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2BmnmzUXm8rUXU%3DSO5NtXjUtYT%3DaJWrALB4ZNow5eo49jg%40mail.gmail.com>
Precedence: bulk

On Sun, Apr 20, 2025 at 10:12=E2=80=AFAM Ivan Kush <ivan.kush@tantorlabs.co=
m> wrote:
> I'm testing OAuth Device Flow implementation on Google. Met several
> problems.

Hi Ivan, thank you for testing and reporting! Unfortunately, yeah,
Google is a known problem [1]. They've taken several liberties with
the spec, as you point out.

We have some options for dealing with them, since their documentation
instructs clients to hardcode their API entry points instead of using
discovery. (That makes it easy for us to figure out when we're talking
to Google, and potentially switch to a quirks mode.)

But! Before we do that: How do you intend to authorize tokens issued
by Google? Last I checked, they still had no way to register an
application-specific scope, making it very dangerous IMO to use a
public flow [2]. Do you have an architecture where this usage is safe,
and/or have they added custom scopes? (I deprioritized handling the
nonstandard behavior when I couldn't prove to myself that it was
possible to use the Google version of Device Authorization safely, but
I'm happy to jump back into that if we have a good use case.)

> 1) In Device Authorization Request Google returns 428 code on pending
> https://developers.google.com/identity/protocols/oauth2/limited-input-dev=
ice#authorization-pending

Right. I believe there were other nonstandard errors in other corner
cases, too. :(

> I suggest to add a GUC in postgresql.conf that contains additional
> non-standard error codes for a specific service.
> oauth_add_error_codes =3D [
>    {
>           issuer: google
>          add_err_codes: [428],
>      },
>      {
>          issuer: someservice
>          add_err_code: [403],
>      }
> ]
> So Google can contain 400,401,428

The server config doesn't help us much, since this is a client-side
feature. Any "global" configuration is probably going to be done
through environment variables or a service file [3].

> Additionally write parsing of such json-like config-values. Will be cool
> to create serializer, that matches struct to such json-like GUC.

I'm not too excited about a separate configuration DSL. I'm guessing
most end users, if they really want Google as their Device
Authorization provider, would rather have us switch over to "Google
mode" once we notice the magic Google endpoint is in use.

> 2) Google requires client_secret only in the Device Access Token Request
> (Section 3.3 RFC-8628).
> ...
> But Postgres sends client_secret in both request, also in Device
> Authorization Request.

Yes. See 3.1 (Device Authorization Request):

   The client authentication requirements of Section 3.2.1 of [RFC6749]
   apply to requests on this endpoint, which means that confidential
   clients (those that have established client credentials) authenticate
   in the same manner as when making requests to the token endpoint, and
   public clients provide the "client_id" parameter to identify
   themselves.

> I suggest to remove send secret on Device Authorization Request.

This breaks Okta, at minimum. We can't do it across the board. (As for
Azure, I haven't figured out how to configure it to *require* a
confidential client secret for the device flow -- which makes a
certain amount of sense since the flow is public -- but its v2
endpoint doesn't mind being *sent* a secret.)

> 3) Additionally if secret exists PG sends it only using Basic Auth. But
> RFC contain only MAY word about Basic Auth. Section 2.3.1 RFC 6749,