# Ziti edge login fails in 2.0.0 when edge-oidc and edge-management are on separate listeners **URL:** \ **Category:** General Questions\ **Created:** [July 27, 2026, 10:48am UTC](https://openziti.discourse.group/t/ziti-edge-login-fails-in-2-0-0-when-edge-oidc-and-edge-management-are-on-separate-listeners/5969 "2026-07-27T10:48:51Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![jnsfndr](https://avatars.discourse-cdn.com/v4/letter/j/d9b06d/32.png) [@jnsfndr](https://openziti.discourse.group/u/jnsfndr)\ **Post date:** [July 27, 2026, 10:48am UTC](https://openziti.discourse.group/t/ziti-edge-login-fails-in-2-0-0-when-edge-oidc-and-edge-management-are-on-separate-listeners/5969/1 "2026-07-27T10:48:51Z")
We upgraded a controller from 1.6.17 to 2.0.0 and `ziti edge login` stopped working. Both CLI and controller are v2.0.0. Also tested it with a fresh install. The default config is everything one listener. We split ours into two, edge-client and edge-oidc on 443, edge-management, fabric and the console on 444. We don't want the management API accessible by everyone. Port 444 is firewalled down to a single static IP. I saw this config in the forum for hardening purposes. This is what we ended up with: ```yaml web: - name: client-management bindPoints: - interface: 0.0.0.0:443 address: ctrl1.example.com:443 apis: #- binding: edge-management - binding: edge-client options: { } - binding: edge-oidc options: { } - name: admin-management bindPoints: - interface: 0.0.0.0:444 address: ctrl1.example.com:444 apis: - binding: edge-management options: { } #- binding: edge-client # options: { } - binding: fabric options: { } #- binding: edge-oidc # options: { } - binding: spa options: path: zac ... ``` The controller advertises all of this correctly: ```json "edge-client": { "v1": { "apiBaseUrls": ["https://ctrl1.example.com:443/edge/client/v1"] } }, "edge-oidc": { "v1": { "apiBaseUrls": ["https://ctrl1.example.com:443/oidc"] } }, "edge-management": { "v1": { "apiBaseUrls": ["https://ctrl1.example.com:444/edge/management/v1"] } }, "fabric": { "v1": { "apiBaseUrls": ["https://ctrl1.example.com:444"] } } ``` Under 1.6.17 this was fine. Logging in against the management port just worked: ```auto $ ziti edge login Enter controller host[:port] (default localhost:1280): localhost:444 Enter username: admin Enter password: Token: cc68c868-... Saving identity 'default' to /root/.config/ziti/ziti-cli.json ``` With 2.0.0, login against 444 gives us: ```auto Error: failed to initiate authorization flow: could not find auth request id header from authorize endpoint ``` On a test controller with the same layout we got a more detailed version of what looks like the same failure: ```auto Error: failed to initiate authorization flow: authentication request start failed with status 404, either a misconfigured request was sent or the expected redirect URL (http://localhost:8080/auth/callback) is not allowed: 404 page not found ``` And against 443: ```auto Error: [POST /authenticate] authenticate (status 404): {} ``` On 1.6.17 it falls back to the legacy `/authenticate` path? What fixed it for us was uncommenting `edge-oidc` on the management listener: ```yaml - name: admin-management apis: - binding: edge-management - binding: edge-oidc # added - binding: fabric - binding: spa ``` After that `/oidc/.well-known/openid-configuration` returns 200 on both 443 and 444, and `ziti edge login ctrl1.example.com:444 -u admin` works again. Access over ZAC works fine without the second oicd listener. So, a few questions: 1. Is running `edge-oidc` on two listeners actually OK? We've now got it bound on both 443 and 444 and it works, but I'd rather know up front if that causes issues with issuer or redirect-URI handling, token audience, key material, or anything specific to an HA cluster. 2. Is there a supported way to point the CLI at one host:port for OIDC and a different one for the management API or is it just a bug? Keeping the management API off the public port is a hardening requirement for us, so if binding OIDC twice turns out to be a bad idea we'd need another way to do this. Happy to post full configs or more logs if that helps. ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [July 28, 2026, 12:31pm UTC](https://openziti.discourse.group/t/ziti-edge-login-fails-in-2-0-0-when-edge-oidc-and-edge-management-are-on-separate-listeners/5969/2 "2026-07-28T12:31:56Z")
Hi @jnsfndr, it took me a while to track it down and be able to understand what was going on in order to be able to answer your questions: > 1. Is running `edge-oidc` on two listeners actually OK? Yes, it's actually mandatory on every listener you want to authenticate against in 2.0+. We tried to do this by default with [Enable OIDC API by default · Issue #3597 · openziti/ziti · GitHub](https://github.com/openziti/ziti/issues/3597) but there seems to be a bug with the implementation that didn't account for multiple web listener binding sections... I've filed [edge-oidc auto-binding is skipped entirely if any one web entry declares it · Issue #4185 · openziti/ziti · GitHub](https://github.com/openziti/ziti/issues/4185) to track this issue. So adding it explicitly is **the right thing to do**. As to your second question: > 1. Is there a supported way to point the CLI at one host:port for OIDC and a different one for > the management API I think about this the other way around. It's that second part that's the important point: "Keeping the management API off the public port". You can definitely do this as you have discovered. You need to add edge-oidc to that private api listener section like you did (for now). Also note with 2.0+ you can also use your own OpenZiti overlay (or a separate overlay) to access this api if you prefer to go that route but having it exposed on some private IP space certainly is a good first step.