Re: [PATCH 0/2] android: register OpenID Connect callback activity for #4281

["Shan Shaji" <s.shaji@proxmox.com>]

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=gemini#name-backend-for-frontend-bff
- [1] https://lore.proxmox.com/all/20250429150757.130996-1-a.abraham@proxmox.com/T/#t
- [2] https://datatracker.ietf.org/doc/html/rfc8252#section-8.12