Closed inventorematto closed 4 days ago
Yeah, can confirm the behavior which I also would consider being a bug. Especially as there is an older bug (https://github.com/goauthentik/authentik/issues/4715)
I confirm. I have exactly the same problem with the second outpost I created. A remote address solves this problem but looks ugly.
I'm facing a similar issue. In my case, I used AUTHENTIK_HOST: http://authentik-server:9000
and AUTHENTIK_HOST_BROWSER: https://auth.my-domain.xyz
.
The connection between the proxy and server seems to work fine according to the logs and web interface, but using the proxy fails with the error message described in the original post.
Confirming also the issue with release 2024.6.2. Definitely a bug.
As others pointed, this is still happening, even on latest rel (2024.6.3)
It's still happening on 2024.8.3.
"error":"oidc: id token issued by a different provider, expected \"http://my-authentik.security.svc.cluster.local/application/o/my-app/\" got \"https://authentik.my-domain.com/application/o/my-app/\"","event":"failed to redeem code","level":"warning","logger":"authentik.outpost.proxyv2.application"
There is a workaround of using the external authentik URL as AUTHENTIK_HOST instead of the internal one. This works but will have other implications, as example now the whole internal traffic goes through the WAF and External Nginx.
So i did a bit analysing. The issue seems to happen in line 59 of /internal/outpost/proxyv2/application/oauth_callback.go.
When the token is verified the context has "AUTHENTIK_HOST" as issuer and not "AUTHENTIK_HOST_BROWSER" which creates the error oidc: id token issued by a different provider, expected %q got %q
in oidc/verify.go on line 267.
This gives us two possibilities, either allow to set config.SkipIssuerCheck
to skip this check, because the signature is still verified or use the right issuer.
What I still don't get is, where the "AUTHENTIK_HOST_BROWSER" is loaded into the context. Because in the end, the code should just replace AUTHENTIK_HOST with AUTHENTIK_HOST_BROWSER when it comes to the verify step. Then the error would be fixed.
As you can see, I created a pull-request tackling this issue: https://github.com/goauthentik/authentik/pull/11722
In the mean-time i pushed a docker-image with the fix applied on my github, if you need this fix immediately: https://github.com/users/chrootlogin/packages/container/package/authentik-proxy
Describe the bug Hello dear team, i'm here to report a bug (maybe), but first let me explain my setup.
I do have a central authentik server running inside my home homelab using almost the standard docker compose file to bring it up.
In order to expose some of my internal services on the internet i use a VPS running in the cloud (outsitde my homelab) connected via ZeroTier to my homelab. As reverse proxy i use Nginix Proxy Manager.
So i deployed a Proxy outpost on the VPS referring to the Manual Outpost deployment in docker-compose documentation, modifing a bit the compose file to fit my setup. This was made to have a local outpost and avoid unecessary traffic from and to the VPS server.
Here the compose file of the outpost proxy:
I can see the Proxy Outpost on the Authentik admin page and i'm able to assign providers to it.
Screenshots
So i configured Nginix Proxy manager using the template (as always done in my local nginix proxy manager inside my homelab) but instead to point to the authentik server i pointed to the Proxy outpost IP/port.
When i try to access the esposed resoruce and i got this log message in the outpost proxy container:
warning warning error=oidc: id token issued by a different provider, expected "https://x.x.x.x:9443/application/o/my-app/" got "https://authentik.mydomain.xxx/application/o/my-app/" event=failed to redeem code logger=authentik.outpost.proxyv2.application name=Emby_VPS-proxy timestamp=2024-05-07T08:49:47Z
And this in the browser happens:
Looks like something is not working here...
The only thing that worked for me is to modify the compose file and put hostname (https://authentik.mydomain.xxx) on the AUTHENTIK_HOST instead of the internal IP address. This to me is not an elegant solution because in this way the container reaches the main authentik server using the public internet (cloudflare tunnel ecc..) instead of using the private ip over the ZeroTier tunnel.
Another route i tested was to create a static entry in my host file and attach that on the container so to force the use of the hostname, but pointing to the private IP.
Expected behavior The expected behavior is to use the private IP to communicate to the main authentik server while being able to use the AUTHENTIK_HOST_BROWSER env to inform the proxy and not have the error 400.
Version and Deployment (please complete the following information):