I am wondering what was the thought process and justification behind removing

--dangerous-force-http

in V2? I mean I'm usually annoyed by the 'security best-practices' stance core team takes, like e.g with not supporting implicit grant, but at least in that case I can't help but admire the decision, fwiw it is opinionatedness in the name of good security hygiene. But what happened here? I have my

<http://hydra-admin.auth.svc.cluster.local>

endpoint that is absolutely internal: only oathkeeper and my backend sees it for admin stuff. I also have a public

<https://auth.actual-domain.com>

endpoint that proxies the external requests for public apis, terminating TLS and then connecting to hydra via regular 'dangerous-unsafe' http. Today I upgraded hydra to V2 only to discover that

--dev

won't save me, because hydra is too smart for its own good and will redirect to https. The whole point of the server is to issue, maintain, and verify tokens, it has no business dictating how the request is coming unless I'm saying it to do so. The docs guide recommends terminating TLS on the gateway and then use I presume self-signed certificates internally for hydra server, on which I thought I call BS, but okay, let's try. I have

<https://hydra-admin.auth.svc.cluster.local>

now, it uses a self-signed certificate I spent effort to provision and mount to the hydra container. I thought it's unnecessarily wasteful, but whatever, changed the introspection endpoint in my oathkeeper config to reflect the

https

and tada!

Post "<https://hydra-admin.auth.svc.cluster.local/oauth2/introspect>": x509: certificate signed by unknown authority.

What the heck? I went back to see the docs guide to discover that the recommended way is to use nginx and proxy all requests without terminating TLS, but deny inbound requests based on the IP, so e.g only allow 127.0.0.1. This whole thing is meaningless, in some sense an anti-pattern, and I say straight up hostile.