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

[andwei]

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

[schwabe]

The focus from my side was mostly on SAML and tradtional MFA, so that why AUTH_PENDING with crtex and WEB_AUTH exists. That was just the requirements that mostly interesting from the products that I work on.

Implementing something similar to the CR_RESPONSE response from the client like CR_AUTH_TOKEN or similar that uses a very similar mechanism to allow a client to just send some 'random' data for authentication is enough to be implemented from the protocol perspective.

Claming https:// URIs is probably a major problem here. An app can basically only claim a small set of URLs, so everyone using something like vpnauth.blinkt.de as redirect and then everyone else ending up on my website is not a great idea, so you probably need to use something like de.binkt.openvpn://oauth-continue or something like that.

It is basically just that nobody has spent any time implementing a better OAUTH flow or if people did they did not contribute back/collaborate with the OpenVPN devs. I was not even aware of that vpn-oidc client until now.

[andwei]

Thanks for your reply and the insights provided!

With regard to the redirect URIs for mobile apps: Thanks for pointing that out. It seems indeed to be a problem I wasn't fully aware of, focussing on desktop apps with a theoretically interchangable loopback redirect-uri.

Thanks again, gives me something to think about 🤔