Re: [PoC] Federated Authn/z with OAUTHBEARER - Mailing list pgsql-hackers

From Ivan Kush
Subject Re: [PoC] Federated Authn/z with OAUTHBEARER
Date
Msg-id 227ce390-b604-4b1b-924a-1540729d8e3a@tantorlabs.com
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Jacob Champion <jacob.champion@enterprisedb.com>)
List 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



pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: AIO v2.5
Next
From: Tom Lane
Date:
Subject: Re: Memory context can be its own parent and child in replication command