Bug: OIDC Login incorrect redirect URL construction behind reverse proxy

[JoelJoos]

I am running OpenUEM behind a reverse proxy (caddy, configuration as defined in this repository) and trying to integrate OIDC authentication with Authentik.

Problem

Login via Authentik fails because OpenUEM generates an invalid redirect_uri:
https://https://openuem.example.com/oidc/callback

I have tried messing with header manipulation

Environment

OpenUEM deployed via docker-compose
Reverse proxy: nginx in front (SSL termination)
internal proxy: Caddy (used for TLS/mTLS on auth port)
Auth provider: Authentik
Console runs on port 1323
Auth runs on port 1324

What I have verified

No https:// is set in any OpenUEM environment variables
SERVER_NAME, REVERSE_PROXY_SERVER, DOMAIN env vars are hostname-only
Redirect URI in Authentik is correct and matches expected callback
Direct access to console port (without proxy) also does trigger malformed redirects

Proxy header debugging

I used a header-echo container (mendhak/http-https-echo) directly upstream of OpenUEM to capture the exact headers OpenUEM receives.
Relevant headers observed:

{
  "host": "uem.example.com",
  "x-forwarded-host": "uem.example.com",
  "x-forwarded-proto": "https",
  "x-forwarded-port": "443",

  "x-original-url": "https://uem.example.com/",
  "x-forwarded-scheme": "https",
  "x-forwarded-uri": "/",
  "x-forwarded-method": "GET"
}

This suggests OpenUEM may be using headers like X-Original-URL or X-Forwarded-Uri (which already contain a scheme), and then prepends https:// again, resulting in double schemes.

Mitigations attempted

I tried all of the following (individually and in combination):

1. Force clean headers. Explicitly set:

• Host
• X-Forwarded-Host
• X-Forwarded-Proto
• X-Forwarded-Port

2. Strip conflicting headers. Removed:

• X-Original-URL
• X-Forwarded-Uri
• X-Forwarded-Scheme
• Forwarded
• X-Forwarded-Method
• X-Original-Method

Result:
Either double https reappears or host becomes empty (redirect_uri=https:///oidc/callback)

3. Single-proxy setups. Tested:
   Browser → nginx → OpenUEM
   Browser → nginx → Caddy → OpenUEM
   Browser → Caddy → OpenUEM

All show the same issue when proxied.

Conclusion / suspected root cause

OpenUEM appears to:
Derive its external base URL dynamically from request headers
Prefer headers like X-Original-URL or X-Forwarded-Uri
Does not robustly normalize or validate scheme/host combinations
Has no explicit configuration option to define a canonical external URL
This makes OpenUEM extremely fragile behind common reverse proxies, especially nginx-based ones that inject X-Original-* headers.

I’m happy to test patches or provide more header dumps if needed.

Cheers and hats off to you and this product!
Joel

[doncicuto]

Hi @JoelJoos, thanks for opening the issue. Let me have a look, it's surely a bug, I'll give you an answer asap

[doncicuto]

Hi @JoelJoos, I've found the error and today hopefully will release a patch with the new docker compose file for the new release

[JoelJoos]

Hi @doncicuto , thank you for resolving this that quickly! I will redeploy it this evening and will give you feedback / close this issue if I can verify the changes have the expected outcome. AFAICT the changes have modernized the setup massively.

One sidenote: For connecting the OpenUEM services together (locally), you could just use the docker-internal hostnames, no? eg. for connecting the console to the ocsp responder, we could just use the service/container name instead of the publicly available hostname? I'm asking because apart from NATS, all other services only have to be accessible internally as far as I can tell. I have tested this and it works once you add the OpenUEM hostname to the NATS certificate creation domains. This way, all communication stays docker-internal and doesn't have to make rounds to DNS / Proxy servers and all OpenUEM services can run under the same subdomain.

Cheers & thanks again!
Joel

[doncicuto]

Hi @JoelJoos
thanks to you, I did a test with Authentik and Caddy after I changed the redirect code so I appreciate the double check, I hope it works.

About the names of the components you're totally right about the connectivity inside Docker for most of the components however I thought it would be better to use hostnames as you may want to use components on different hosts and the certificates are generated with those names. I tried to create a compose file that may mimic the other Linux and Windows deployments but it may be better to improve the compose file in the future based on your feedback

Cheers and enjoy the season!

[JoelJoos]

Hi @doncicuto, thank you for your effort.

Sadly, it still is a bit incorrect: After the sign in flow, authentik wants to redirect to OpenUEM using a port:

• 1323 if deployed without caddy -> probably intended and correct (if not running behind an external proxy)
• empty port openuem.example.com:/oidc/callback if deployed with caddy -> incorrect, probably still a bug.

IMO, for production setups, it should be possible to have the whole stack under one URL, behind a reverse proxy (if running on different hosts, you can still do the port forwarding on said proxy). I managed to achieve this by setting all the *_HOST variables to the same hostname (which would cover this production setup case), but the redirect URL construction still seems incorrect.

Cheers and happy holidays!

[doncicuto]

Hi!
thanks for your testing and sorry for the inconvenience. In my case I had Caddy listening on port 1325 and authentik got the right redirect, so I guess in your case it is not getting the port from the referer and that empty port is doing really bad. I'll have a look to fix this in a few days, probably next week.

Yes, you're right about the production url, I still need to polish the Docker deployment. Also people would like to be able to use a path like example.com/openuem instead of ports so I'll try to tackle this issue as well. As the log un with digital certificates will no be mandatory we won't need to use the auth port and we can simplify the compose file a little more.

I'll keep the issue updated to discuss my findings

[doncicuto]

Hi @JoelJoos, happy new year!

I'm moving the issue to the console repo as this issue may affect Docker and Windows/Linux deployments

[doncicuto]

About your previous test with Docker and Caddy, did you set the REVERSE_PROXY_HOST, REVERSE_PROXY_CONSOLE_PORT and REVERSE_PROXY_AUTH_PORT env variables in the .env file? These env variables inform the console that a reverse proxy is used so the redirect URI is built.

In any case, I've just built a Docker image for the console labeled as testing that you could add in the openuem-console service section in the docker compose file to test if at least the empty port issue is fixed when building the redirect URI:

 image: openuem/openuem-console:testing

Thanks for your help

[JoelJoos]

Hi @doncicuto, sorry for the late reply.

Yes, I have set the REVERSE_PROXY* variables when testing with Caddy.

The issue seems to be fixed now and the URL is constructed correctly.

Thank you for your swift support. I'll leave this issue open in case you want to merge the testing changes into main before closing it.

Do you have another method of donating other than Amazon?

Cheers!

[doncicuto]

No! thanks to you for your feedback, testing and for opening the issue. And yes, I'll keep the issue opened until I merge all the changes

In the first quarter of the year, probably, I'll add a GitHub Sponsor option so anybody can donate and fund some expenses (it takes time to do it properly for taxes and legal stuff), thanks for considering a donation