Issues getting self-hosted solution working with Apache reverse proxy

[ksorensen76]

Environment

  System:
    OS: Linux 6.5 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (4) x64 Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
    Memory: 2.03 GB / 7.75 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 20.9.0 - ~/.nvm/versions/node/v20.9.0/bin/node
    npm: 10.1.0 - ~/.nvm/versions/node/v20.9.0/bin/npm
  Browsers:
    Brave Browser: 125.1.66.110
    Chrome: 125.0.6422.76
    Chromium: 125.0.6422.60
  npmPackages:
    @auth/unstorage-adapter: ^2.1.0 => 2.1.0 
    next: latest => 14.2.3 
    next-auth: ^5.0.0-beta.18 => 5.0.0-beta.18 
    react: ^18.3.1 => 18.3.1 

Reproduction URL

https://github.com/ksorensen76/next-auth-example

Describe the issue

When trying to get the site up and running, using https://authjs.int/ with an Apache proxy, the site works fine to browse. However, upon signIn(), the provider gives the error The redirect URI 'http://authjs.int/api/auth/callback/microsoft-entra-id' specified in the request does not match the redirect URIs configured for the application. The issue is the 'http' in the attempted redirect URI vs 'https' that the site and the provider are configured to use.

When inspecting the site and browsing it, under Application -> Cookies, I have:

• authjs.callback-url: http%3A%2F%2Fauthjs.int
• authjs.csrf-token: (token string)

So it is passing around an http callback-url rather than the needed https.

The only changes to next-auth-example are:

1. Updating all packages to use next-auth 5.0.0-beta.18
2. Modifying the auth,ts to use microsoft-entra-id and trustHost: true
3. Modify auth-components.tsx to set the provider in await signIn('microsoft-entra-id') so it directs straight to the provider rather than having to click another signIn button (and avoid a csrf-token error).

Other than that, .env.local looks like this:

# app settings
NODE_ENV=development

# nextauth
AUTH_SECRET=(redacted)
AUTH_TRUST_HOST=true

#entra id
AUTH_MICROSOFT_ENTRA_ID_ID=(redacted)
AUTH_MICROSOFT_ENTRA_ID_SECRET=(redacted)
AUTH_MICROSOFT_ENTRA_ID_TENANT_ID=(redacted)

Apache site conf looks like this:

<IfModule mod_ssl.c>
  <VirtualHost _default_:443>
    ServerName authjs.int
    ServerAdmin webmaster@localhost

    ProxyPreserveHost On
    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/

    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/authjs-ssl.crt
    SSLCertificateKeyFile /etc/ssl/private/authjs-ssl.key
  </VirtualHost>
</IfModule>

I have tried multiple different things, like setting the AUTH_URL in the .env file, setting the X-Forwarded-Proto header in the site conf file, and most everything else I can think of. My main application is experiencing the same issue as the modified next-auth-example code so I have been able to reproduce it.

How to reproduce

Navigate the site, click the 'Sign In' button,

Expected behavior

After sign in, it should redirect back to https://authjs.int/.

[masterjanic]

@ksorensen76 Seems like the basePath inside your auth config is configured incorrectly. Looking at your docker-compose file you are setting it to http://localhost:3000/auth but in your case it would need to be http://localhost:3000/api/auth as far as I can tell. On your production server you will also need to set it to the correct url with https.

[ksorensen76]

@masterjanic I am not using the docker file (that is just a remnant from the next-auth-example codebase), just running npm run dev and then using Apache to forward from the test domain to http://localhost:3000. The problem is that it is sending the wrong protocol (http instead of https) in the redirect url sent to the provider.

[masterjanic]

@ksorensen76 Huh yeah thats weird. My guess would be that you still need to set an AUTH_URL to https://authjs.int/api/auth. Otherwise it got to be some problem with your Apache config, because the protocol / hostname can't be detected correctly.

I can't really help you there since I don't use Apache but reading the docs when using ProxyPassReverse it says:

Only the HTTP response headers specifically mentioned above will be rewritten. Apache httpd will not rewrite other response headers, nor will it by default rewrite URL references inside HTML pages. This means that if the proxied content contains absolute URL references, they will bypass the proxy.

Maybe this is related to your issue.

[ksorensen76]

@masterjanic Well, it looks like I still need AUTH_URL due to auth.js not detecting the proper protocol even with it being sent in the X-Forwarded-Proto header. It detects the URL properly, but not the protocol. Well, after trying your suggestion of adding in the AUTH_URL of https://authjs.int/api/auth, I got some [auth][warn][env-url-basepath-redundant] errors, so I removed the /api/auth and now it seems to be working.

I am almost positive that I had tried that before several times, but maybe something else was different. I will load up my actual codebase and see if that resolves the issue there as well.

Thanks!