"you see, at some point in time the password was bypassed for users on local network 192.168.1.0/24, however the traefik ingress lives on 192.168.1.1"
which of course is his real problem (reverse proxy, microservices). And of course he has to double down and pile on even more complexity as the solution, instead of throwing out all the crap he's stacked together and coming up with something simple, performant and sane.
Personally I wouldn't bother with that and instead I would not directly expose the service to the internet at all, and just use a VPN. I don't trust that any services I run are safe to expose to the internet unless they are very intentionally designed for that.
At the end of the post I mention, that having proper separation would've helped, but again, that's a whole project...
For things not supporting OIDC natively there's OIDC Proxy for traefik. So in this case the solution is adding a label requesting the OIDC Proxy Middleware, and adding a redirect URL to the OIDC application.
You could argue that it's "more complexity", but routing it through a home vpn, for instance, is also "more complexity".
What, in your opinion is "simple, performant, and sane"? You casually throw that around, but never explain...