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: