Setting up OIDC auth with Nextcloud behind a reverse proxy

[granite steeple]

Both my Authentik and Nextcloud instances are sitting behind a traefik reverse proxy in a kubernetes cluster

I am following the following tutorials for the setup:
https://www.schiessle.org/articles/2023/07/04/nextcloud-and-openid-connect/

https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#authentik

However, if use their internal DNS names for the discovery and redirect URIs (or just the discovery), Nextcloud tries to redirect me to the internal Authentik URL for authentication.

What am I missing?

How can I setup OIDC auth when the provider and relying party are sitting behind a reverse proxy?

Actually, I just tested accessing:

http://authentik-http.ix-authentik.svc.cluster.local:10230/application/o/nextcloud/.well-known/openid-configuration

and

https://my.domain.com/application/o/nextcloud/.well-known/openid-configuration

The configuration URLs domains differ depending on where the request has come from. When accessed from the external domain it returns the external domain name, while when called from the internal - returns the internal

AFAIK OpenID auth is all backend based (ie cleint should not be able or need to access the discovery endpoint, or pass any tokens back and forward like it is the case with SAML)

Is this a bug?

[granite steeple]

Ok, did some digging. I think this is indeed a bug. Unless I am misunderstanding how I am supposed to configure this, I think the problem comes from here:

https://github.com/goauthentik/authentik/blob/e60820a9d1d9fe14570d7a512b7fbd50fa00d1d1/authentik/providers/oauth2/views/provider.py#L48-L92

Since self.request contains the domain the client used to access the endpoint build_absolute_uri builds an absolute URI with the client's domain. But in the case of OIDC behind reverse proxy, the client is the relying party and it is accessing the endpoint through an internal domain name

[granite steeple]

@gleaming hare can you please confirm if this is indeed a bug?

[gleaming hare]

the reverse proxy is supposed to set X-Forwarded-For which is picked up and used when building the URL and with that it'll have the correct URL

[granite steeple]

How can this be achieved with traefik when both authentik and nextcloud inside the cluster

Isn't the discovery endpoint supposed to be accessed by nextcloud directly, and not by the user?

[gleaming hare]

I dont use traefik so I can't really help with that, sorry

[gleaming hare]

yes in this case but some oauth methods use it client-side too

is there any issue with setting nextcloud to use https://my.domain.com/application/o/nextcloud/.well-known/openid-configuration?

[granite steeple]

This will resolve to the public ip i think so it won't work without internet

Also I would prefer to not have the discover endpoint exposed outside the cluster. It's probably okay to do so (?), but just in case.

Juat to understand

From where to where should x-forwarded-for be set

User accesses nextcloud though reverse proxy. Nextcloud accesses the discovery endpoint through internal dns. Authentik returns the endpoints with intern dns names. Nextcloud passes those back to the user

How do I transform those when returning them back to thr user?

[granite steeple]

What does authentik need to always return the endpoints with the public domain?

[misty salmon]

Hi @granite steeple Have you managed to fix this issue as I'm facing it as well with NPM.

[granite steeple]

Yes. There is now a tutorial https://goauthentik.io/integrations/services/nextcloud/#openid-connect-auth

What do you mean with NPM?

[misty salmon]

NGINX Proxy Manager

I managed to get the correct redirect URL, however I keep getting this error: "You must access Nextcloud with HTTPS to use OpenID Connect"

[granite steeple]

Well you must access authentik's https endpoint behind the proxy

[misty salmon]

I made sure all the endpoints are https, however I am now trying to see if it is a cert issue:

https://goauthentik.io/integrations/services/nextcloud/#extra-configuration-when-running-behind-a-reverse-proxy

[granite steeple]

Are you accessing port (i believe) 9443 of authentik?

https://goauthentik.io/docs/installation/docker-compose#configure-for-port-80443

9000 is http, 9443 is https

By default

Your proxy should access 9443 and should also expose an https port for external connections

[misty salmon]

Not sure where should I assign that port, I usually access authentik via port 9000 however none of the setup items of nextcloud contain any reference to any port number.

For reference, attached is my Authentik-nextcloud OIDC setup, and here is my advanced setup in NPM:

`client_body_buffer_size 512k;
proxy_read_timeout 86400s;
client_max_body_size 0;

location / {
proxy_pass $forward_scheme://$server:$port;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}

location /.well-known/carddav {
return 301 $scheme://$host/remote.php/dav;
}

location /.well-known/caldav {
return 301 $scheme://$host/remote.php/dav;
}`

[granite steeple]

I csn see you are using your public dns for the discovery endpoint in the nextcloud oidc settings

In that case you do not need to do any extra configuration. You just need to make sure you have a way of reaching your ptoxy's external endpoint from nextcloud

[misty salmon]

Yeah, unfortunately I am still getting the http error in nextcloud..

[rigid osprey]

Any luck with this? I'm facing the same issue