Re: [PoC] Federated Authn/z with OAUTHBEARER

From: Ivan Kush <ivan(dot)kush(at)tantorlabs(dot)com>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Wolfgang Walther <walther(at)technowledgy(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Date: 2025-04-20 17:12:01
Message-ID: 227ce390-b604-4b1b-924a-1540729d8e3a@tantorlabs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello!

I'm testing OAuth Device Flow implementation on Google. Met several
problems.

Postgres from master branch, commit 764d501d24b
Google Device Flow API
https://developers.google.com/identity/protocols/oauth2/limited-input-device

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

Source code handles only 400/401 error codes, they are in the Section
5.2 RFC6749
* An error response uses either 400 Bad Request or 401 Unauthorized.
* There are references online to implementations using 403 for error
* return which would violate the specification.

-----------------
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

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

Or we can create a separate file oauth.conf where json-like data will
be. And postgresql.conf may contain link to this file, name oauth_conf GUC

oauth_conf = /var/lib/postgres/data/oauth.conf

=================

2) Google requires client_secret only in the Device Access Token Request
(Section 3.3 RFC-8628). Also note that secret is in a body of a request
https://developers.google.com/identity/protocols/oauth2/limited-input-device#step-4:-poll-googles-authorization-server

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         https://oauth2.googleapis.com/token

Not Device Authorization Request (Section 3.1 RFC-8628)
https://developers.google.com/identity/protocols/oauth2/limited-input-device#step-2:-handle-the-authorization-server-response

curl -d "client_id=client_id&scope=email%20profile" \
        https://oauth2.googleapis.com/device/code

But Postgres sends client_secret in both request, also in Device
Authorization Request. See calls of a func add_client_identification in
funs start_device_authz & start_token_request
Azure also use secret only in Device Access Token Request
https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-device-code#device-authorization-request
-----------------

I suggest to remove send secret on Device Authorization Request.

=================
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,
if (conn->oauth_client_secret) /* Zero-length secrets are permitted! */
{
username = urlencode(conn->oauth_client_id);
password = urlencode(conn->oauth_client_secret);
...
CHECK_SETOPT(actx, CURLOPT_HTTPAUTH, CURLAUTH_BASIC, goto cleanup);
CHECK_SETOPT(actx, CURLOPT_USERNAME, username, goto cleanup);
CHECK_SETOPT(actx, CURLOPT_PASSWORD, password, goto cleanup);
actx->used_basic_auth = true;
}
Also this section contains words about body, Google use such approach

Alternatively, the authorization server MAY support including the client
credentials in the request-body using the following parameters:
client_id REQUIRED. The client identifier issued to the client during
the registration process described by Section 2.2
<https://datatracker.ietf.org/doc/html/rfc6749#section-2.2>.
client_secret REQUIRED. The client secret. The client MAY omit the
parameter if the client secret is an empty string.
https://developers.google.com/identity/protocols/oauth2/limited-input-device#step-2:-handle-the-authorization-server-response

-----------------
I suggest to set such cases in config. Let's create a json-like oauth
array config. Field auth_scheme shows what scheme we want to use. (see
GUC description in pt1 of this email).
oauth = [
  {
         issuer: google
        add_err_codes: [428],
        auth_scheme: body
    },
    {
    issuer: someservice
        add_err_code: [403],
        auth_scheme: basic
    }

]

--
Best wishes,
Ivan Kush
Tantor Labs LLC

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-04-20 18:18:27 Re: Memory context can be its own parent and child in replication command
Previous Message Alexander Lakhin 2025-04-20 15:00:00 Re: AIO v2.5