OIDC Discovery URLs using authentik-server hostname instead of AUTHENTIK_EXTERNAL_HOST? (v2024.4.2, Docker) #14378
Unanswered
DigitalDharmator
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hey all,
I'm hoping someone can shed some light on an OIDC issue I'm wrestling with using Authentik 2024.4.2 in Docker Compose (with the embedded outpost).
Basically, I have a separate Flask/Authlib service in the same compose network trying to do OIDC login. When the Flask app redirects the browser to Authentik for login, the browser gets sent to http://authentik-server:9000/application/o/authorize/... which obviously fails with an NXDOMAIN error because the browser doesn't know authentik-server. It should be using http://localhost:9000.
Here's what I've checked and confirmed:
My docker-compose.yml definitely has AUTHENTIK_EXTERNAL_HOST: http://localhost:9000 under the environment: section for the authentik-server service.
I've run docker-compose exec authentik-server sh -c 'echo $AUTHENTIK_EXTERNAL_HOST' and it correctly prints http://localhost:9000.
I've restarted everything multiple times using docker-compose down && docker-compose up -d --build.
If I curl http://authentik-server:9000/application/o/ai-job-butler/.well-known/openid-configuration from inside my Flask container, I get the discovery doc back fine (so the client can reach Authentik), but the JSON response clearly shows "authorization_endpoint": "http://authentik-server:9000/..." and similar for the other endpoints.
I've looked through the OIDC Provider settings in the UI (under "Advanced protocol settings") and the embedded Outpost settings, and I don't see any obvious input fields where I could have manually entered authentik-server URLs to override the EXTERNAL_HOST setting.
So, I'm a bit stumped. The environment variable seems correctly set and passed into the container, but Authentik isn't using it when generating the URLs for the OIDC discovery document.
Is this a known quirk with 2024.4.2 or the embedded outpost setup? Or is there some other place I should be looking in the configuration that might be forcing the use of the internal hostname for these discovery URLs?
Really appreciate any ideas! Getting tired chasing this one down.
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions