Support for separate backend request URLS for OAuth providers (like Keycloak)

[kriswuollett]

I've had a goal to try running a Keycloak along with other services and a NextJS app locally before trying to run them out in a cloud. Keycloak and the NextJS server is behind a NGINX reverse proxy. I've had success with this in the past when I was using @react-keycloak/ssr on macOS, but besides trying out next-auth I'm also now trying to run everything within Docker as well.

I'm using v3.29.0 along with this [...nextauth].tx content since I haven't upgraded to the latest to get the Keycloak provider that looks like going to be released with v4:

import NextAuth from "next-auth";
import { OAuthConfig } from "next-auth/providers";

function Keycloak(options: Partial<OAuthConfig>): OAuthConfig {
  return {
    id: "keycloak",
    name: "Keycloak",
    type: "oauth",
    version: "2.0",
    params: { grant_type: "authorization_code" },
    scope: "openid profile email",
    profile: (profile, _) => ({ ...profile, id: `${profile.sub}` }),
    accessTokenUrl: `${options.domain}/protocol/openid-connect/token`,
    requestTokenUrl: `${options.domain}/protocol/openid-connect/auth`,
    authorizationUrl: `${options.domain}/protocol/openid-connect/auth?response_type=code`,
    profileUrl: `${options.domain}/protocol/openid-connect/userinfo`,
    clientId: `${options.clientId}`,
    clientSecret: `${options.clientSecret}`,
    ...options,
  };
}

export default NextAuth({
  providers: [
    Keycloak({
      clientId: process.env.oidc_client_id,
      clientSecret: process.env.oidc_client_secret,
      domain: process.env.oidc_issuer,
    }),
  ],
  debug: true,
});

My issue is only partially fixed by using the NEXTAUTH_URL_INTERNAL parameter. Redirection to the login works, but when the callback happens the server side errors out:

logger.js:11 [next-auth][error][oauth_get_access_token_error] 
https://next-auth.js.org/errors#oauth_get_access_token_error Error: connect EHOSTUNREACH 192.168.1.47:8082
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1146)
    at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130) undefined undefined

The oidc_issuer env is set to something like http://myapp.local:8082/auth/realms/myapp since I'm publishing a http service on mDNS so I can test on macOS through its mDNSResolver and avoid modifying its hosts file. But those oAuth provider URLs seem to be not routable within the Docker bridge network.

Similar to #2509 except all API calls from the server, including the oauth provider routes, have to be mapped to a completely different name. I may be able to work around this by changing my configuration, but seems like it may be a standard use case to allow backends to use different API endpoints than frontend client user-agents as described in [Keycloak's Server Installation guide]. The discussion in #1261 and pull-request #2485 touched on things like process.env. vs. options.domain.

[kriswuollett]

Originally the question was the result of trying to run within Docker in combination with Keycloak. I finally figured out a reasonable method in case someone wanted to set up something similar as a workaround when developing with Docker and come across this thread:

• Create .test domains for your web apps and Keycloak your desktop's /etc/hosts that point to 127.0.0.1
• Update all containers to use a consistent http listener port like 8080.
• The NGINX container is given Docker network aliases for each of the host names in the above /etc/hosts in the docker-compose.yml file.
• The NGINX container proxies to each of the web apps based on the host name
• The base URL for all the OAuth endpoints look like http://auth.test:8080/auth/realms/${appname}

The end result is the web browser on your desktop resolves all those hosts as 127.0.0.1 with port 8080 which is the published NGINX container port. The containers on the inside also use those same host names, but within the Docker network they resolve to the NGINX container's internal IP with its 8080 real listening port. So a different base URL isn't needed for the server-side requests that are running within the private container network.

Otherwise, if you are mainly interested in the server-side URL feature, I've created #2637 for it.

[AlanPedro]

Hey Kris - we've hit the same block here trying to run Next in docker compose with a reverse proxy and keycloak.

Did you manage to find another fix to the issue or is this still what you used?