Hi Evan and Daniel, We are running with mod_openidc in production since late 2022. This includes some elaborate apache configs to allow both browsers and Subversion clients to access the same URLs protected by AuthType openid-connect (session cookie). This works in combination with an installed application containing our code that performs the OpenIDC authentication (perhaps similar to GCM, not sure) and provides that session token to the Svn client. It would be very interesting to make some enhancements to the Subversion client to simplify the setup.
> This all works with git, using Git Credential Manager > <https://github.com/git-ecosystem/git-credential-manager> (GCM; this is > a cross-platform .NET Core app). Thanks for mentioning GCM, perhaps worth investigating. > The repo runs behind Apache httpd, which is using mod_auth_openidc. The > config file sets 'AuthType openid-connect', and 'Require valid-user'. > (1) HTTP requests need to specify 'Authorization: Bearer' with an access > token. Are you sure mod_openidc accepts a Bearer token when configured with AuthType openid-connect? > If you don't have an access token, something (a script, GCM, > whatever) has to pop up a browser window and connect to an OAuth2 > identity provider (IdP). The user then logs in (with MFA if configured), > and the IdP then redirects back to localhost with a token. This is not the approach we have taken (due to complexity and uncertainty related to protecting the app registration client-secret). We let mod_openidc handle as much complexity as possible. > This means > that the 'script' must also run a webserver to extract the token, which > it can then add to the GET/POST/whatever request. We avoid this temporary webserver by redirecting to an application URL-prefix registered in the OS. It is valid to register application URLs as returnUri when registering an OpenIDC application with the IdP (but that's not quite how we are doing it though...). The temporary "code" in the code flow is shipped to the application via the URL-prefix. The application then exchanges the code for the session token. > 1. Why "tunnel the session token in basic auth"? Because we are in production since late 2022 and we have to use some authentication mechanism that the Subversion clients currently support. > Does he want HTTP basic auth /and/ HTTPS mod_openidc_module? No. > How does a session token fit in with basic anyway? We are tunneling the session cookie from mod_openidc as the password part of Basic Auth. The Basic auth username is not important because mod_openidc will figure it out from the session. I developed some Apache black magic to transform the basic auth password into a cookie consumed by mod_openidc. This black magic can be removed if the Svn client is enhanced with some Cookie support. > 2. I don't quite understand the 'svn auth' comments - is Thomas > suggesting /manually/ recording tokens and cookies? If we have an application/script that performs authentication, it could make the session token available to the Svn client via the "svn auth" subcommand (with some enhancements). Or it can just run "svn info https:/... --token ..." in order to insert it into the Svn client auth cache (with some small enhancements). > 3. Any solution must have bearer tokens /and/ cookies - but that's > obvious, so presumably I've misunderstood the post I would say bearer tokens OR cookies. The decision btw those 2 options is a very fundamental design decision. I opted for minimal complexity -> Cookie. With different trade-offs one could potentially end up preferring bearer tokens but the client-secret and complex client configurations need to be figured out (we want to be able to deploy to hundreds of extremely non-technical users). Best regards, Thomas Åkesson
