Strange redirect_uri bug in self-hosted 4.6.1

Hey all. I’m looking for any advice at all on this. It’s possible we’re overlooking something silly, but I’ve searched through all the documentation and threads that I can find.

We have a self-hosted instance running 4.6.1 and using the v2 login UI. First of all, we are having issues with organization discovery (“User not found in the system”), but I believe this is already a known and tracked bug according to GitHub.

However, we’re even having trouble signing into the default organization with a configured external OIDC provider. On hitting the button, we get an error from our IdP about mismatching redirect_uri’s.

Zitadel is requesting we configure the IdP to allow

https://domain.com/ui/v2/loginidps/callback

https://domain.com/ui/v2/loginidps/callback

https://domain.com/ui/v2/loginidps/callback

https://domain.com/ui/v2/loginidps/callback, but the actual request made by Zitadel to the IdP when hitting the external login button looks like

https://domain.com:443/idps/callback

https://domain.com:443/idps/callback

https://domain.com:443/idps/callback

https://domain.com:443/idps/callback

If I add that second callback uri (with the port) to the IdP configuration, then when I click the button I now get an error from Zitadel (“An error occurred while trying to login.”)

So it seems to me that the error might be caused by Zitadel adding in the 443 and then getting confused by it. Is my understanding right, or does anyone have any ideas what I might be doing wrong? I believe we are running a fairly standard setup and configuration. Running behind an AWS ALB.

Ask Inkeep•11/4/25, 8:38 AM

Hi @lbm, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.

Ask Inkeep•11/4/25, 8:38 AM

Answer

I wasn't able to find a direct answer, here are some relevant sources:

Handle External Logins in a Custom Login UI : Covers the external identity provider flow and callback handling, noting that the redirect URL is `https://$%7BCUSTOM_DOMAIN%7D/idps/callback%60 when using the V2 hosted login. (1)
ZITADEL Default Settings : Explains identity provider configuration at the instance level and domain settings that might affect callback behavior. (2)

Ask Inkeep•11/4/25, 8:38 AM

To learn more, see the sources I considered:

[1] Handle External Logins in a Custom Login UI
[2] ZITADEL Default Settings

Ask Inkeep•11/4/25, 8:38 AM

Feel free to tag @Ask Inkeep with additional questions.

lbmOP•11/4/25, 8:42 AM

That answer is a bit confusing, since the actual in-app documentation after configuring and external OIDC provider is specifically to use https://domain.com/ui/v2/loginidps/callback for v2 callbacks. Yet that article does indicate it’s the latter (without the port).

So I guess the two questions are:

Which one is correct?
Why is our instance adding the 443 port to the initial IdP request?

AAsk Inkeep To learn more, see the sources I considered: [[1] Handle External Logins in a...

Ask InkeepAPP•11/4/25, 9:00 AM

Got it. Tagging @Rajat for additional help.

lbmOP•11/5/25, 2:55 PM

Humbly pinging @Rajat for any assistance. Granted we are not paying users, but that’s not for lack of want! If the cloud offering ever becomes available in Japan, we’d love to talk

This issue is blocking adoption by a number of our internal teams who are willing to give it a try. So I want to resolve this quickly to keep the momentum going.

Rajat•11/5/25, 6:28 PM

hey @lbm thanks for the ping and welcome to the server. Let me read it and I will get back to you

Rajat•11/5/25, 7:47 PM

hey @lbm
We only host cloud in US, Switzerland, Germany and Australia. The closest would be Australia for you. You can always self host if you want the data and implementation to be in Japan. Will that be an option?.

lbmOP•11/6/25, 12:31 AM

@Rajat Oh sorry, that was just a remark. It wasn’t the actual question I’m having.

I need help with this OIDC error.

lbmOP•11/11/25, 11:18 PM

@Ask Inkeep we still need help with this

Ask Inkeep•11/11/25, 11:18 PM

Thanks for the follow-up, @lbm. I'll get back to you soon.

Ask Inkeep•11/11/25, 11:18 PM

Answer

There is direct evidence that with the v2 login UI, ZITADEL changed the callback URL for external IdPs to use the path /idps/callback rather than /ui/login/login/externalidp/callback, and this was a known issue for some setups (1) questions-help-bugsCallback URL for Microsoft IDP . The documentation and community discussions confirm that you should configure your IdP to accept https://your.domain.com/idps/callback as the redirect URI when using v2 login UI .

If ZITADEL is adding :443 to the callback URL, this could be related to how your reverse proxy or load balancer (such as AWS ALB) is forwarding headers or reconstructing the original request, but there is no explicit documentation detailing ZITADEL’s port handling in the callback URL questions-help-bugsCallback URL for Microsoft IDP . Ensuring your ALB is forwarding the correct host and scheme headers may help, but the official guidance is to use /idps/callback for v2 (1) questions-help-bugsCallback URL for Microsoft IDP .

Ask Inkeep•11/11/25, 11:19 PM

To learn more, see the sources I considered:

[1] [Bug]: Incorrect redirect_uri being passed to Microsoft
questions-help-bugsCallback URL for Microsoft IDP

Ask Inkeep•11/11/25, 11:19 PM

Feel free to tag @Ask Inkeep with additional questions.

AAsk Inkeep To learn more, see the sources I considered: [[1] [Bug]: Incorrect redirect_u...

Ask InkeepAPP•11/11/25, 11:19 PM

Got it. Tagging @Rajat for additional help.

lbmOP•11/11/25, 11:20 PM

We’re confident upstream ALB issues aren’t the culprit. It was working before v4 with no changes to this part of the cloud infra.

Hank•11/20/25, 2:43 PM

@lbm hey, did you ever solve this? I believe we are seeing the very same error

lbmOP•11/20/25, 11:19 PM

No, I’ve booked a call with their enterprise licensing team to see if we can get any guidance that way. I’ll report back for you if I find out anything helpful.

Thanks, it’s useful to know it might be affecting other teams too

lbmOP•11/20/25, 11:19 PM

@Rajat

lbmOP•11/24/25, 3:50 PM

@Hank Just had that call. I believe Zitadel will kindly have someone take a look at this thread

Hank•11/24/25, 3:52 PM

Thanks! We also have a call today in 40mins

It's not 100% identical to your issue but it's definately related

Matías•11/24/25, 6:01 PM

Hi @lbm, sorry about the late reply. I'm taking a look at this now, just wanted to let you know. I'll get back to you, most likely tomorrow, with an update about the reported issue.

FFO•11/24/25, 10:00 PM

Hey folks, would you be able to share how zitadels config looks like?

I suspect something along the TLS settings that makes zitadel include the known port.

lbmOP•11/25/25, 5:49 AM

@ffo thanks for the patience! How does this seem?

lbmOP•11/25/25, 5:51 AM

If there’s any value you want me to inspect in more detail, let me know and I can take a look.

Hank•11/25/25, 8:23 AM

We have the same set up more or less, AWS LB -> EKS -> NGINX Ingress -> Zitadel. Same set up with ExternalPort 443, ExternalDomain set, Zitadel is configured with TLS enabled

Hank•11/25/25, 12:23 PM

@lbm hey, not sure if this applies to you as well but we had a small breakthrough this morning, we had the login container talk directly to zitadel using a hostAlias, changing this to have it go out to the LB and back in via EKS -> NGINX and changing the backend-protocol defindition to nginx.ingress.kubernetes.io/backend-protocol: GRPCSnginx.ingress.kubernetes.io/backend-protocol: GRPCS changes so the port is no longer automatically added anymore

Hank•11/25/25, 12:24 PM

Switching back either to using hostAlias or reverting back to http2 makes the port issue appear again

Hank•11/25/25, 12:24 PM

@Matías @ffo FYI

FFO•11/25/25, 7:30 PM

Uhm interesting, this must come down somehow to nginx adding the port into the host header then.

What envs did you pass to the login? I think ATM you would need to set - CUSTOM_REQUEST_HEADERS=Host:${ZITADEL_EXTERNALDOMAIN}- CUSTOM_REQUEST_HEADERS=Host:${ZITADEL_EXTERNALDOMAIN}to make it work when internally calling the API