OIDC with Cloudflare proxied domains

[reddwarf666]

Hi There!

We had some conversation 1 month ago and I chose to stay with NPM. #66
I had Pocket-ID working finally but I was not completely happy with it as I find having only passkey a bit limiting and I had to create a setup where every container I wanted to protect with Pocket-ID needed a separate instance of OAuth2-Proxy. Not a solid setup I think.
Started to look at Keycloak to replace Pocket-ID and my issues in this regard with NPM were bad. So bad that I thought to abandon NPM.
Thought about Godoxy again and wanted to give it a second chance!

Did all you said I had to do and I have Godoxy running. Easy, simple and I like it! Thanks for the push at the time, it made the transition easier.

Before I continue with the issue I have with using Keycloak as OIDC provider, I collected some thoughts and things I encounter.
I don't want to overload this thread with several things and wondered if you want me to create separate issues or dump them in this thread?

Now the Keycloak issue I face. I have it running and I "think" I have it setup OK.

But once I try to make Keycloak the OIDC provider for Godoxy, I face some problem. The log of Godoxy does not tell me enough to hunt and fix this alone so I need your help with this.

Error in Godoxy log

03-19 19:07 FTL failed to initialize authentication error="failed to initialize OIDC provider: 404 Not Found: {\"error\":\"Unable to find matching target resource method\"}"
Container stopped

Note: I could not find any errors in the entrypoint.log. I cleared it and started Godoxy to make sure I did not miss anything but it remains empty after starting Godoxy. I guess this issue is so soon that logs are not written to.

Here is some information you might need. I redacted where needed for privacy reasons.

Config for route to Keycloak (file called keycloak.yml stored in /config):

auth:
  scheme: http
  port: 8080
  middlewares:
    set_x_forwarded:
  homepage:
    show: true
    name: Keycloak
    category: oidc
    description: User federation, strong authentication, user management,
      fine-grained authorization .
  host: 192.168.2.192
  load_balance:
    link: ""
    mode: ""
  no_tls_verify: true
  healthcheck:
    disable: true

(Note: host IP address here is the internal docker host IP address)

Config in .env for OIDC:

GODOXY_OIDC_ISSUER_URL=https://auth.example.com
GODOXY_OIDC_CLIENT_ID=godoxy
GODOXY_OIDC_CLIENT_SECRET=NotTheRealSecretOfCourse
GODOXY_OIDC_REDIRECT_URL=https://example.com/api/auth/callback
GODOXY_OIDC_SCOPES=openid, profile, email
GODOXY_OIDC_ALLOWED_USERS=steven
GODOXY_OIDC_ALLOWED_GROUPS=godoxy_allusers

Config relevant I think from Keycloak compose file:
KC_HOSTNAME: auth.example.com
KC_PROXY_HEADERS: xforwarded

Perhaps related, not quite sure:
keycloak/keycloak#31168 (comment)

And I wanted to mention this as it might be relevant.
When I started Keycloak for my Godoxy setup I could hardly logon to Keycloak
https://auth.example.com/admin/master/console/
9 out of 10 times that failed with some weird non-descript error in the browser:

somethingWentWrong
somethingWentWrongDescription

(I'm not making this up 😀!)

I read the Keycloak docs and found this:
Using a reverse proxy
https://www.keycloak.org/server/hostname

When a proxy is forwarding http or reencrypted TLS requests, the proxy-headers option should be set. Depending on the hostname settings, some or all of the URL, may be dynamically determined.
	If either forwarded or xforwarded is selected, make sure your reverse proxy properly sets and overwrites the Forwarded or X-Forwarded-* headers respectively. To set these headers, consult the documentation for your reverse proxy. Misconfiguration will leave Keycloak exposed to security vulnerabilities. 

Hence I set this on my route for “auth”:

middlewares:
    set_x_forwarded:

This worked really well...until I faced that OIDC issue and then this came back, I can hardly logon to Keycloak again, same weird message.

Any ideas what could be wrong or what to do here?

[yusing]

I've just tested KeyCloak with following docker compose, I can login to Keycloak without issue but not able to setup OIDC either. My suggestion is try to use Authentik instead.

services:
  keycloak:
    image: quay.io/keycloak/keycloak:26.1.4
    restart: no
    container_name: keycloak
    environment:
      KC_HOSTNAME: keycloak.i.sh
      KC_HOSTNAME_STRICT_BACKCHANNEL: "true"
      KC_BOOTSTRAP_ADMIN_USERNAME: admin
      KC_BOOTSTRAP_ADMIN_PASSWORD: admin
      KC_HEALTH_ENABLED: "true"
      KC_LOG_LEVEL: info
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health/ready"]
      interval: 15s
      timeout: 2s
      retries: 15
    command: ["start", "--http-enabled=true", "--proxy-headers", "xforwarded"]
    labels:
      proxy.*.port: 8080

[reddwarf666]

Ok, thanks. I will look into Authentik.
By the way, I was looking around and stumbled across this:
https://github.com/vouch/vouch-proxy/blob/master/config/config.yml_example_gitea

Would that work for Godoxy? I mean, I have Gitea running in my setup so... 😀

[yusing]

Actually I'm not sure why you want things like OAuth2-Proxy and vouch.

You can simpily set these environment variables and then enable oidc middleware per app like this:

labels:
  proxy.yourapp.middlewares.oidc:

[reddwarf666]

Oh, not wanting it, I was just surprised Gitea could be used as a OIDC.
I will go with what you support and Godoxy supports. And I saw in the docs Godoxy supports Authentik so I will see where that takes me.

[reddwarf666]

Ok, I have Authentik running! Yay!

However, I could logon/start with the URL: https://auth.example.com/if/flow/initial-setup/
But I could access Authentic via the internal docker host address: http://docker_host:9000/if/flow/initial-setup/
So I can also see now : http://docker_host:9000/if/admin/#/administration/overview
I could create a new user, disable the default admin, logon with my new account. All looks well.

The message in a browser:
Request failed. Please try again later

My route file in Godoxy:

auth:
  scheme: http
  port: 9000
  middlewares:
    set_x_forwarded:
  homepage:
    show: true
    name: ""
    category: ""
    description: ""
    icon: https://cdn.jsdelivr.net/gh/selfhst/icons/webp/authentik.webp
  host: 192.168.2.192
  load_balance:
    link: ""
    mode: ""
  healthcheck:
    disable: true

Is there anything I need to look at from Godoxy point of view?

[yusing]

Remove the set_x_forwarded middleware and try again

Are you running authentik LXC or docker btw?

[reddwarf666]

Thanks. Tried that just now and get the same error. I thought to add that setting as in other solutions it was needed I think to set it. I'm running Authentik in Docker.

I was wondering about 3 things in the Authentik setup:
1)
AUTHENTIK_COOKIE_DOMAIN
Would I need to set that?
I had it set to example.com initially and got the same message. Then commented it out but same result.
Perhaps setting it to auth.example.com is needed?

2)

CLOUDFLARE_IPS
LOCAL_IPS

I saw some config from Brokenscripts where it was set like so:

CLOUDFLARE_IPS=173.245.48.0/20,103.21.244.0/22,103.22.200.0/22,103.31.4.0/22,141.101.64.0/18,108.162.192.0/18,190.93.240.0/20,188.114.96.0/20,197.234.240.0/22,198.41.128.0/17,162.158.0.0/15,104.16.0.0/13,104.24.0.0/14,172.64.0.0/13,131.0.72.0/22
LOCAL_IPS=127.0.0.1/32,10.0.0.0/8,192.168.0.0/16,172.16.0.0/12

Would that make sense?

3)

AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS
From : https://github.com/brokenscripts/authentik_traefik/blob/traefik3/my-compose/.env
# AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS: CHANGEME_IFAPPLICABLE 
# Defaults to all of: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fe80::/10, ::1/128

This one seems to make a lot of sense somehow.

Perhaps you can have an idea about these and if they are needed?

[yusing]

For docker containers, you should use docker labels instead of route files. If you want to use it in a NPM way (create routes manually on WebUI), enable explicit mode like this to avoid route conflicts:

# config.yml
...
providers:
  docker:
    local!: $DOCKER_HOST # add a ! after the name

I'm not sure why you have got into that error. Let me give you an example docker compose file for authentik (basically default compose.yml with three labels added) and the .env file:

---

services:
  postgresql:
    image: docker.io/library/postgres:16-alpine
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 5s
    volumes:
      - ./data/db:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${PG_PASS:?database password required}
      POSTGRES_USER: ${PG_USER:-authentik}
      POSTGRES_DB: ${PG_DB:-authentik}
    env_file:
      - .env
  redis:
    image: docker.io/library/redis:alpine
    command: --save 60 1 --loglevel warning
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 3s
    volumes:
      - ./data/redis:/data
  server:
    image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2024.10.1}
    labels:
      - proxy.aliases=auth
      - proxy.auth.port=9000
      - proxy.auth.healthcheck.disable=true
      - proxy.auth.middlewares.redirect_http
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
      AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
    volumes:
      - ./media:/media
      - ./custom-templates:/templates
    env_file:
      - .env
    depends_on:
      - postgresql
      - redis
  worker:
    image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2024.10.1}
    restart: unless-stopped
    command: worker
    labels:
      - proxy.#1.healthcheck.disable=true
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
      AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
    # `user: root` and the docker socket volume are optional.
    # See more for the docker socket integration here:
    # https://goauthentik.io/docs/outposts/integrations/docker
    # Removing `user: root` also prevents the worker from fixing the permissions
    # on the mounted folders, so when removing this make sure the folders have the correct UID/GID
    # (1000:1000 by default)
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./media:/media
      - ./certs:/certs
      - ./custom-templates:/templates
    env_file:
      - .env
    depends_on:
      - postgresql
      - redis

#.env
AUTHENTIK_TAG=2025.2
PG_PASS=REDACTED
AUTHENTIK_SECRET_KEY=REDACTED
# SMTP Host Emails are sent to
AUTHENTIK_EMAIL__HOST=smtp.mail.me.com
AUTHENTIK_EMAIL__PORT=587
# Optionally authenticate (don't add quotation marks to your password)
AUTHENTIK_EMAIL__USERNAME=REDACTED
AUTHENTIK_EMAIL__PASSWORD=REDACTED
# Use StartTLS
AUTHENTIK_EMAIL__USE_TLS=true
# Use SSL
AUTHENTIK_EMAIL__USE_SSL=false
AUTHENTIK_EMAIL__TIMEOUT=10
# Email address authentik will send from, should have a correct @domain
AUTHENTIK_EMAIL__FROM=REDACTED
AUTHENTIK_REDIS__DB=1

So basically the default docker compose and dotenv should work, without those stuff you have mentioned above.

[reddwarf666]

Thanks for the help!

Applied all you suggested to my setup and still face that issue.
Welp, now I will delete everything Authentik I did and start new with your suggestions, clean slate.
I will report back!

[reddwarf666]

One more thing, if you try this setup from scratch, do you start docker compose as root?
I run it as myself (1000:1000) so I wanted to make sure if this is done the same as you did.

[reddwarf666]

Ok, I took the sample you gave and and replaced only the REDACTED parts with my info, like passwords and so on.
Deleted all folders and files I had and started docker compose up -d
Same result unfortunately. "Request failed. Please try again later."
As the ports are not exposed in the compose file I could also not access Authentik locally, but that is understandable.

I think there is something not right in routing via the labels, as if something is missing or something like that.
But then again, I do get a screen from Authentic so it must be reachable, just not able to log on and start the initial process.
https://auth.example.com/if/flow/initial-setup/

Any ideas? I feel I'm so, so close...

[yusing]

I've just tried to setup from scratch, as myself (1000). I cannot reproduce the error, it just worked...

Could you check for the logs from those authentik containers when you hit https://auth.example.com/if/flow/initial-setup/? Also network logs from browser's DevTools.

[reddwarf666]

I saw some HTTPS authentication issues I think

The logs are available: https://we.tl/t-esv0Xe31Cl

Thanks!

[yusing]

That's weird. Updated the docker compose above, added a redirectHTTP middleware, see if it works for you.

[reddwarf666]

Now I see another message when I try
https://auth.example.com/if/flow/initial-setup/

Chrome:

This page isn’t working
auth.example.com redirected you too many times.

[Try deleting your cookies](https://support.google.com/chrome?p=rl_error&hl=en-GB).
ERR_TOO_MANY_REDIRECTS

Firefox:

The page isn’t redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

    This problem can sometimes be caused by disabling or refusing to accept cookies.

From the network tab in developer mode:

{
	"Status": "301",
	"Version": "HTTP/3",
	"Transferred": "601 B (0 B size)",
	"Request Priority": "Highest",
	"DNS Resolution": "System"
}

{
	"Response Headers (601 B)": {
		"headers": [
			{
				"name": "alt-svc",
				"value": "h3=\":443\"; ma=86400"
			},
			{
				"name": "cf-cache-status",
				"value": "DYNAMIC"
			},
			{
				"name": "cf-ray",
				"value": "9238f8f388a58ade-AMS"
			},
			{
				"name": "content-type",
				"value": "text/html; charset=utf-8"
			},
			{
				"name": "date",
				"value": "Thu, 20 Mar 2025 23:26:05 GMT"
			},
			{
				"name": "location",
				"value": "https://auth.example.com/if/flow/initial-setup/"
			},
			{
				"name": "nel",
				"value": "{\"success_fraction\":0,\"report_to\":\"cf-nel\",\"max_age\":604800}"
			},
			{
				"name": "report-to",
				"value": "{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report\\/v4?s=z%2BBPLWp3UMq5rdCOq%2BWYqJtSM%2FgLvCNmlu%2FJbXnJ7bN7Y8rjhRzhmtv2Rf5leRUNw47QZV2IrswfzDBMTCr5aN6kxJ8DxSraBiJdkAJ9grgShpCf7j23DOvTcG2mgoaIzkA5%2F2QGCAjqtitGUIU%3D\"}],\"group\":\"cf-nel\",\"max_age\":604800}"
			},
			{
				"name": "server",
				"value": "cloudflare"
			}
		]
	}
}

And just before that message/row:

{
	"Status": "301",
	"Version": "HTTP/3",
	"Transferred": "599 B (0 B size)",
	"Request Priority": "Highest",
	"DNS Resolution": "System"
}
{
	"Response Headers (599 B)": {
		"headers": [
			{
				"name": "alt-svc",
				"value": "h3=\":443\"; ma=86400"
			},
			{
				"name": "cf-cache-status",
				"value": "DYNAMIC"
			},
			{
				"name": "cf-ray",
				"value": "9238f8f368a38ade-AMS"
			},
			{
				"name": "content-type",
				"value": "text/html; charset=utf-8"
			},
			{
				"name": "date",
				"value": "Thu, 20 Mar 2025 23:26:05 GMT"
			},
			{
				"name": "location",
				"value": "https://auth.example.com/if/flow/initial-setup/"
			},
			{
				"name": "nel",
				"value": "{\"success_fraction\":0,\"report_to\":\"cf-nel\",\"max_age\":604800}"
			},
			{
				"name": "report-to",
				"value": "{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report\\/v4?s=g9o%2Fcdaqo54et2be5pzzc0U9uiHLuE8858m0TJ9v1obe7SnNt%2BPUeO5jelaOy%2F9zEtGvGhJKYEMIwkjezJh%2FEJB1KdSd9rPCbSKfqoI1jUBYLcQwUDN9slVBdFxi8Bhgull9GHZDP0kWpeIZyqg%3D\"}],\"group\":\"cf-nel\",\"max_age\":604800}"
			},
			{
				"name": "server",
				"value": "cloudflare"
			}
		]
	}
}

Screenshot of that window: