From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id BEA261FF0B3 for ; Fri, 11 Sep 2026 17:44:45 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 47D87214BF; Fri, 11 Sep 2026 17:44:44 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 11 Sep 2026 17:44:30 +0200 Message-Id: To: "Azharul Haque" Subject: Re: [PATCH 0/2] android: register OpenID Connect callback activity for #4281 From: "Shan Shaji" X-Mailer: aerc 0.20.0 References: <20260810054037.17184-1-haque@azharul.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1789141459423 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.326 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: T7UX3M7LALSQ3FW5OCPYKIM4QA7NDK5U X-Message-ID-Hash: T7UX3M7LALSQ3FW5OCPYKIM4QA7NDK5U X-MailFrom: s.shaji@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Azharul, Please consider this as an initial reply. On Thu Sep 10, 2026 at 12:37 AM CEST, Azharul Haque wrote: > Hi Shan, > > Dug into the server side before replying. PVE's /access/openid/auth-url > and /access/openid/login (src/PVE/API2/OpenId.pm in pve-access-control) > only take {realm, redirect-url} and {state, code, redirect-url} > respectively, no code_challenge/code_verifier field in the API for a > client to plug into. Thanks for taking the time to dig into this. I was aware about this. Should have mentioned this in my earlier reply. Sorry! [snip] > 2. state+code leaks after our app has them but before they reach PVE: > a crash reporter snapshotting the callback URL, a logging proxy in > between, or something on a compromised device reading it out from > under the app, an > Android accessibility-service/clipboard scraper, a rogue iOS > keyboard extension, I couldn't understand how the above services can access the parameters. > MDM profile either way. Nothing defends this today, not the > platform APIs (they only guard the redirect hop), not PVE's > server-held verifier (it never checks who's calling /login), and > it's identical exposure on both platforms since it's the same > /login endpoint either way. Without server-side changes, we could fetch the authorization URL and open it in an embedded WebView (embedded user agent). The PVE HTTPS origin could be used as the redirect URI. The app could intercept navigation to that URI, extract both the code and state parameters, and submit them to /access/openid/login, similar to this implementation [1]. However, AFAIU, this is against the RFC 8252 8.12 [2]. Also, didn't completely go through the code changes in that series. > Real client-side PKCE would close that second gap: app generates a > verifier, sends the challenge at auth-url time, PVE forwards that > challenge to the IdP instead of its own, and /login requires the > verifier back before it'll redeem the code. But we can't add that from > the app alone, /login has no code_verifier field to send it to. > It'd need a pve-access-control change to accept a client-supplied > code_challenge/code_verifier and use that instead of (or in addition to) > the one it generates itself now. [snip] > Is a server-side change along those lines something you'd consider, or I'm not entirely sure about that, as I haven't had a chance to go through the code yet. Perhaps someone else could chime in; otherwise, I'll investigate and get back to you in the coming days. > is there a reason PVE holding the verifier itself instead of the client > is a deliberate design choice I'm missing? I think it has some BFF [0] like properties but I have to double check it. Will get back. [snip] - [0] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-= apps?utm_source=3Dgemini#name-backend-for-frontend-bff - [1] https://lore.proxmox.com/all/20250429150757.130996-1-a.abraham@proxmo= x.com/T/#t - [2] https://datatracker.ietf.org/doc/html/rfc8252#section-8.12