Re: [PoC] Federated Authn/z with OAUTHBEARER

On Sun, Apr 20, 2025 at 10:12 AM Ivan Kush <ivan(dot)kush(at)tantorlabs(dot)com> 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-device#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 = [
> {
> 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,

From 2.3.1:

The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.

We rely on that MUST, at the moment. We can add an exception for a
provider, certainly, but it needs to be limited for safety reasons:
"Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
to directly utilize the HTTP Basic authentication scheme..."

(Authentication is its own nasty minefield; OAuth introduced its own
encoding requirements on top of HTTP that a bunch of servers ignored,
but in practice we cross our fingers that servers will only issue
ASCII credentials if they're not willing to follow the encoding
rules...)

So to recap: I'm happy to add a Google compatibility mode, but I'd
like to gather some evidence that their device flow can actually
authorize tokens for third parties safely, before we commit to that.
Thoughts?

Thanks!
--Jacob

[1] https://postgr.es/m/CAOYmi%2BkTumP6FHwLnUKX0DVKrTv%3DN9xSOAu7YMH_XKSMP7ozfA%40mail.gmail.com
[2] https://postgr.es/m/CAOYmi%2B%3DMFyrjDps-YNtem3%3DGr3mUsgZ49m7bfMCgr1TDjHL58g%40mail.gmail.com
[3] https://www.postgresql.org/docs/current/libpq-pgservice.html