Configuring URL for OAuth2

Questions
1

Hello,
we would like to run n8n and have a public endpoint for webhooks, but I might be missing something: the configuration variables seems a bit confusing.

I have a private host (say 192-168-10-10.nip.io) with n8n in it, http only, and a public host (say n8n.example.com) that should forward only the webhook traffic and keep all the other endpoint safe and closed.

To do this, I used the following envvars:

# internal address
N8N_HOST=192-168-10-10.nip.io

# reverse proxy
WEBHOOK_URL=https://n8n.example.com/

But running n8n with this configuration will result in OAuth Redirect URL (e.g. when configuring GitHub OAuth credentials) to be https://n8n.example.com/rest/oauth2-credential/callback

Though, this means that /rest/ endpoints should be exposed as well via the proxy, but here Jan mentions that “only the webhook-endpoints and /healthz should work without authentication”.

I am unsure on how to proceed here: it seems that either oauth2 endpoints shouldn’t depend on WEBHOOK_URL, but I might be missing something in the configuration. I tried using the VUE_APP_URL_BASE_API but had no effect on the OAuth Redirect URL.

What’s the path here? Should I allow /rest/oauth2-credentials/callback to be public as well? What are the other endpoints that should be public? Isn’t /rest/* supposed to be private?

Thanks

2

Hi @Alessandro_Re, I think the comment linked might be outdated seeing it’s related to version 0.54.0, but maybe @jan can confirm this with certainty.

OAuth2 initiated by n8n would indeed use a redirect URL of /rest/oauth2-credential/callback path so I typically allow this in my reverse proxy config.

1 Like
3

Ok, thank you. I wonder if there is some kind of reference of the API which are supposed to be public. Maybe the server setup documentation could be updated to include this kind of information.

I couldn’t find a page specifically for setting up n8n securely, but I guess that would be useful as well.

4

Thanks, this is a very good point.

That said, does having basic auth handled by your proxy on /rest/oauth2-credential/callback cause any trouble for you? After all this is a browser redirect, so as long as your browser can access the path you should be good.

5

No problem, that is actually our current setup. The issue arises from the fact that there might be untested routes: if there are other paths that ought to be public, we will not know until we use them :grinning_face_with_smiling_eyes: