OIDC login fails with Authentik – callback request uses localhost inside container and token exchange returns unexpected response

[listiges-kaenguru]

Description:

I am running Pangolin and Authentik on the same VPS, each in its own Docker Compose setup. Authentik is already successfully used as an Identity Provider for other services, so the OIDC setup itself is working in general.

However, when configuring Authentik as an IDP in Pangolin, the login flow does not complete successfully.

---

Steps to reproduce:

1. Run Pangolin in Docker (separate compose project)
2. Run Authentik in Docker (separate compose project)
3. Configure Authentik as OIDC provider in Pangolin
4. Start login via Pangolin → redirect to Authentik works
5. After authentication, callback fails in Pangolin

---

Expected behavior:

OIDC login should complete successfully and redirect back to Pangolin with a valid token.

---

Actual behavior:

Login fails during token exchange / callback validation.

Pangolin logs show:

pangolin | Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/generate-url
pangolin | Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/validate-callback
pangolin | 2026-05-07T13:42:18+00:00 [error]: OIDC provider returned an unexpected response during token exchange {"status":200}

---

Observations:

• Pangolin is calling its own internal API using http://localhost:3000
• Since Pangolin runs inside Docker, localhost likely refers to the container itself rather than the host or reverse proxy
• The callback validation returns HTTP 200, but the response is considered invalid/unexpected
• Authentik itself works correctly with other OIDC clients, so the issue seems Pangolin-specific

---

Possible causes / suspicions:

• Misconfigured base URL or issuer URL in Pangolin OIDC settings
• Hardcoded localhost inside the container instead of service name / network alias
• Docker networking issue (Pangolin container cannot resolve correct internal service endpoint)
• Incorrect redirect URI / callback URL mismatch between Authentik and Pangolin
• Response format mismatch during token exchange even though HTTP status is 200

---

Environment:

• Pangolin running in Docker (separate Compose stack)
• Authentik running in Docker (separate Compose stack)
• Both services installed per default as documented by publisher
• No special-configuration
• Same VPS host

---

Question:

Is it expected that Pangolin uses localhost:3000 internally for OIDC callback validation?
If yes, how should this work correctly in a Dockerized multi-stack setup?

Or is this an indication of a misconfiguration / bug in how internal API URLs are generated?

[AstralDestiny]

I use authelia and don't have the issue, can you provide what you configured in pangolin omitting any secrets but still populating so we know what it looks like?

[listiges-kaenguru]

It worked in the past. Don´t know since when it is broken. Here are my settings.

[listiges-kaenguru]

Just figured this out:

Option 1 to make it work

The issue is caused by Pangolin trying to reach Authentik through the Pangolin-proxied public URL instead of directly via the internal network.

I originally configured the OIDC endpoints like this:

• https://auth.example.com/application/o/authorize/
• https://auth.example.com/application/o/token/

Since Authentik itself was behind Pangolin, the token exchange returned an unexpected response and Pangolin logged:

OIDC provider returned an unexpected response during token exchange {"status":200}

The fix was to configure Pangolin to use the internal Authentik address instead of the public proxied URL, for example:

• http://public-ip:9000/application/o/authorize/
• http://public-ip:9000/application/o/token/

After switching to the direct internal endpoint, OIDC login worked correctly.

Option 2 to make it work

I also found another working solution.

The issue only occurred because the Authentik instance itself was protected by Pangolin access control. In that setup, Pangolin tried to perform the OIDC token exchange against an endpoint that was again gated by Pangolin authentication, which resulted in the unexpected response error.

If I disable access control for the Authentik application in Pangolin, the public proxied URL works correctly as the OIDC endpoint, for example:

https://auth.example.com/application/o/authorize/
https://auth.example.com/application/o/token/

So there are two possible fixes:

• Use the internal Authentik address directly (http://public-ip:9000/...)
• Keep using the public Pangolin-proxied URL, but disable Pangolin access control for the Authentik application itself

---

I am not very happy with this. Do you have any idea on how to work with my pangolin-protected url for authentic?

I tried with a rule to skip auth from my country, my ip, ..... No luck.

[Draugor]

for anyone else wandering in here, i had similiar struggles and figured my solution might help someone else:
if the OIDC provider runs in the same docker/podman network: use containername:internal_port/oidc-token-path/ as token url
if it runs behind a newt side, use <auth_domain>:<gerbil_interal_https_port>/oidc-token-path/ and in your compose-file for gerbil add:

networks:
      default:
        aliases:
          - <auth_domain>

Sidenote: it might work without the port in the token URL if you bind gerbil/traefik to the standard-ports, why i had to add the port:
my setup overall is a bit wild because i use podman rootless and run every image as a user, so i had to do some port shenanigens to fix some stuff (gerbil-ip showed in traefik logs instead of users-ip, not able to bind to privilaged ports) i setup firewalld port forward 80/443 to 8080/8443 -> haproxy host-network 8443 to 127.0.0.1:8444 -> traefik/gerbil bind 127.0.0.1:8444:8445
(haproxy-redirect fixes a podman/traefik issue, that otherwise shows the internal container ip in its logs)