Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHugY-0003aB-9M for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Jan 2023 22:44:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pHugX-0005qS-3q for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Jan 2023 22:44:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHugW-0005qJ-Pm for pgsql-hackers@lists.postgresql.org; Tue, 17 Jan 2023 22:44:04 +0000 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pHugU-0001aX-Gy for pgsql-hackers@postgresql.org; Tue, 17 Jan 2023 22:44:04 +0000 Received: by mail-pl1-x630.google.com with SMTP id p24so35022313plw.11 for ; Tue, 17 Jan 2023 14:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timescale.com; s=google; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=OUJVMUB5OXSvknjmfjxWhthJKQ/9EiEEYFMl5MzJCAI=; b=ZS00MEq+Ix1t1wkGTmwr1BxrigjUSL+WeB4KVkDgUmLI2qizrL4mtDBszUkuyDUBj4 CsplubwfKKFUG7xfB1DCEoShgCV/KyMPmxWobNW2EbQ5b9CApVJB56rvxtAydu4J2JZb CJMipiD3t/Je18yOvV6Ep/STjjntpIgeYF38hXks1TNeSOHqoYGYDWeaH13iDVOglCH4 FSsfzgBEM5TbKXbUkX1PoFbV3y2dqIPm+GhlHXqW76mEEXJibdLq4d3iwC08GiYpGll6 s9XFgL+I986UAbG5XzONf1BeQngBCBd3ICpOPpnEw3bVDxTotqrA1CBp4ER4JQRBVgjT ftpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OUJVMUB5OXSvknjmfjxWhthJKQ/9EiEEYFMl5MzJCAI=; b=EubTDkPTUY42bIJ6eIZhvL523QTkiO4cMqOG/1qjAgU/rZy98KM35mgJQIlEiCrKoj DZwrAv53xU2ryTZ9r1gLzXY2dTtWnqPYpma+QdFPYUaiSY3lryrDrWkaWHsNgi4ae1/q aiuoE9jnFLwLBOtmDafMPzAOVcPYvzHRNAxASoinmORAsLkp/ou7wSKr8l3qTOE7YUw8 ZXuA+LrLQlYAP4UL6e0XkOQBKtYwM1Er1o0clhF1Z3W+tivPgno5pqYP323HPHnxPQDx ydXJXCVPvD+il8Nt/Sk4/Koh4KgGcZMoBgSKQkg4WYbLiXD9db9B8Sf8J8EjJAC65a2n R1mw== X-Gm-Message-State: AFqh2kq/Oo38iLXLwGQUUawK5wyPgZPQC+uIfddJrbBn0Q2SSxt4OFcl F6QyGppVfxangoD6NtSf8zsn9g== X-Google-Smtp-Source: AMrXdXsn27neIpUqxcWaIdoirPogiaeQ9V7nSggZ8ZbH611qdVNqNKt6lHlF1Xtd9lTUOYV3xzi1EA== X-Received: by 2002:a17:90a:2dcf:b0:219:5955:7570 with SMTP id q15-20020a17090a2dcf00b0021959557570mr4264006pjm.46.1673995440120; Tue, 17 Jan 2023 14:44:00 -0800 (PST) Received: from [192.168.1.21] ([50.53.8.205]) by smtp.gmail.com with ESMTPSA id z1-20020a17090a468100b0022932d12de1sm42660pjf.46.2023.01.17.14.43.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Jan 2023 14:43:59 -0800 (PST) Message-ID: Date: Tue, 17 Jan 2023 14:43:59 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 From: Jacob Champion Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER To: Andrey Chudnovsky Cc: mahendrakar s , hlinnaka@iki.fi, Michael Paquier , Pg Hackers , smilingsamay@gmail.com References: <705e7eb8-29ee-a707-5a67-d2acfb2f3fad@timescale.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Jan 15, 2023 at 12:03 PM Andrey Chudnovsky wrote: > 2. Removed Device Code implementation in libpq. Several reasons: > - Reduce scope and focus on the protocol first. > - Device code implementation uses iddawc dependency. Taking this > dependency is a controversial step which requires broader discussion. > - Device code implementation without iddaws would significantly > increase the scope of the patch, as libpq needs to poll the token > endpoint, setup different API calls, e.t.c. > - That flow should canonically only be used for clients which can't > invoke browsers. If it is the only flow to be implemented, it can be > used in the context when it's not expected by the OAUTH protocol. I'm not understanding the concern in the final point -- providers generally require you to opt into device authorization, at least as far as I can tell. So if you decide that it's not appropriate for your use case... don't enable it. (And I haven't seen any claims that opting into device authorization weakens the other flows in any way. So if we're going to implement a flow in libpq, I still think device authorization is the best choice, since it works on headless machines as well as those with browsers.) All of this points at a bigger question to the community: if we choose not to provide a flow implementation in libpq, is adding OAUTHBEARER worth the additional maintenance cost? My personal vote would be "no". I think the hook-only approach proposed here would ensure that only larger providers would implement it in practice, and in that case I'd rather spend cycles on generic SASL. > 3. Temporarily removed test suite. We are actively working on aligning > the tests with the latest changes. Will add a patch with tests soon. Okay. Case in point, the following change to the patch appears to be invalid JSON: > + appendStringInfo(&buf, > + "{ " > + "\"status\": \"invalid_token\", " > + "\"openid-configuration\": \"%s\"," > + "\"scope\": \"%s\" ", > + "\"issuer\": \"%s\" ", > + "}", Additionally, the "issuer" field added here is not part of the RFC. I've written my thoughts about unofficial extensions upthread but haven't received a response, so I'm going to start being more strident: Please, for the sake of reviewers, call out changes you've made to the spec, and why they're justified. The patches seem to be out of order now (and the documentation in the commit messages has been removed). Thanks, --Jacob