[ENH] - Mock usage of oauth2-proxy on jhub-apps

[viniciusdc]

Context

We recently started switching our CI/build pipelines to use pixi as our environment manager, and ran into an indirect-pinning bug in simpervisor (the subprocess controller used by both jhsingle-native-proxy in jhub-apps and JupyterHub’s built-in proxy). Full details in nebari-docker-images#209.

We considered two paths forward:

1. Upstream fix
   There’s an open issue to bump the simpervisor dependency in jhsingle-native-proxy (ideonate/jhsingle-native-proxy#22), but upgrading introduces conflicts with the proxy internal configuration.

2. Replace the proxy
   jhub-apps already tracks exploring oauth2-proxy as an alternative (nebari-dev/jhub-apps#125). We decided to prototype oauth2-proxy.

There’s also a PR upstream to extend jupyter-server-proxy so it can spawn arbitrary services, but it still requires custom wrappers to fit our jhub-apps environment—and its implementation effort roughly matches adopting oauth2-proxy today.

This Issue

Track the work to replace jhsingle-native-proxy with oauth2-proxy in jhub-apps.

Benefits

• Eliminates the current simpervisor pin-version bug in our CI images
• Removes dependency on the unmaintained jhsingle-native-proxy
• Leverages a well-supported, community-standard OAuth2 proxy

Next Steps

1. Prototype oauth2-proxy usage within the command line execution of jhub-apps;
   • as a basic example, we should try to get a base panel application working;
2. Update jhub-apps launcher (spawner) and proxy command configuration;
3. Remove all references to jhsingle-native-proxy
4. Validate end-to-end workflows (Panel, Bokeh, Streamlit, etc.)

Additional Context

None at the moment.