Yes, you would set some cookie or whatever and then the JupyterHub Authenticator only reads this cookie instead of allowing a login page. You can see this shibboleth authenticator as an example pattern, which relies on headers set in an apache or nginx shibboleth plugin. This pattern sounds like what you are after.
There are two main choices of pattern:
- the regular hub proxy is the public entrypoint, and your custom LoginHandler redirects to your auth service if the cookie is not set
- your auth service is actually the only public endpoint and it proxies requests to the hub proxy only if they are authenticated
In both cases, instead of a sidecar container on an existing pod, I would use a separate service and deployment for the auth. In the proxy case, the hub proxy-public does not need to be publicly exposed, it can be a private service that is only accessible from your proxy (or at least from inside your cluster).
It would probably be best to use a JWT or other reasonably trusted signed value, if that’s an option available to you.