Handling SSO/Web_Auth flow/tokens within the Openvpn-Client

Hi,

This is a general question, no bug report. I've been digging into the possibilities to use OpenIDConnect (oidc) to authenticate a User at an openvpn-server.

I'm aware of the supported method of using an AUTH_PENDING control message, supplying a redirect-url within a following INFOMSG that triggers the client to open a browser and continue Authentication using a OAuth2/oicd Flow (WEB_AUTH and management-interface).

AFAICT this method always relies on some (openvpn-)server-side https-service that is used as a redirect-uri for the authorization-code flow, e.g. the openvpn-auth-oauth2 plugin, i.e., receiving id_token, refresh_token at the server side and logging the user in from "there".

I'm also aware of the various ways to send an additional challenge to the client using AUTH_PENDING with crtext or the (older?) mechanism of using sending back an error containing the CRV1:<flags>:<state>:<b64(user)>:<challenge-text>. Those are restricted to a strictly textual challenge-response, though.

I was wondering why there seems to be no support for a solution (in the openvpn repos, at least) that only involves the client (be it a "native/desktop app" or a "mobile app" in OAuth2 terms) completing the authorization-code flow (with PKCE) and using the thereby obtained id_token to authenticate with the openvpn-server, in lieu of a password. The redirect-uri for that scenario could either be a loopback addr (http://127.0.0.1:<port>) for desktop or a claimed https:// URI for mobile.

I am aware that it is possible to implement a plugin and custom client (or even a wrapper around the existing client, as was done here) that implements the described "client-local approach". However it seems like a nice thing to have the "official" openvpn-server and client implementing a mechanism and configuration support for oidc in a way that the openvpn-server defines the parameters and the client takes care of the OAuth2-Flow and mangement of the id_token (and in extension, refresh_token etc.).

Am I missing something that makes that approach unfeasible or unsafe? Is it something that has been discussed and been discarded for this or that reason? Or am I overlooking something and it's ready to go and I just can't find it?

Kind regards,
Andreas

Start with doc/webauth.md and the management-notes.txt section on WEB_AUTH, then compare the server-side flow described here with the proposed client-local OAuth2/PKCE approach. A useful outcome would be a maintainer decision on feasibility, security considerations, and whether official client and server configuration support is wanted.