Support backend URLs for oauth/Keycloak providers

[kriswuollett]

Description 📓

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.

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

This is 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.

How to reproduce ☕️

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,
});

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.

Contributing 🙌🏽

Yes, I am willing to help implement this feature in a PR

[kriswuollett]

I originally asked this as a discussion q&a in #2633, but button to transfer/link back to a new issue didn't seem to work.

[stale]

Hi there! It looks like this issue hasn't had any activity for a while. It will be closed if no further activity occurs. If you think your issue is still relevant, feel free to comment on it to keep it open. (Read more at #912) Thanks!

[kriswuollett]

Still interested. Didn't get to potentially working on it myself since was still learning setting up a TS monorepo with NextJS projects.

[stale]

Hi there! It looks like this issue hasn't had any activity for a while. It will be closed if no further activity occurs. If you think your issue is still relevant, feel free to comment on it to keep it open. (Read more at #912) Thanks!

[kriswuollett]

Not stale.

[kriswuollett]

Finally got around to looking into this again. I'm now just configuring DNS request for the external hostname to resolve to Keycloak internal hostname -- easy to do with CoreDNS in Kubernetes in my use case. That seems like the more appropriate way to solve the problem. An alternative of course is a http client proxy, but that is covered in the other issue linked earlier.

@balazsorban44, feel free to close if you don't think there is much other demand for this feature.