SSR requests fail when server is covered with other authorisation method

[St-Permiakov]

Question 💬

Hello!
Big thanks to you for your work: next-auth already helped us a lot.
Sorry in advance for maybe dumb question, but I'm new to all SSR thing.

I have a project with https backend, next and next-auth authorization.
All requests to next-auth api on SSR side fail with errors like these:

https://next-auth.js.org/errors#client_fetch_error providers FetchError: invalid json response body at https://my_domain/api/auth/providers reason: Unexpected token < in JSON at position 0

https://next-auth.js.org/errors#client_fetch_error session FetchError: invalid json response body at https://my_domain/api/auth/session reason: Unexpected token < in JSON at position 0

The same requests on clientside work ok.

My best guess is: this happens due to https.
My next server starts on ordinary http.

The questions are:
Where the problem may really be?
Am I supposed to transfer my next-server to https in order for next-auth to work? Or I should dig the other way?
Is there any way to see those responses (with "unexpected token"). They surely could bring some light to my issue.

next-auth config:

const options = {
  providers: [
    {
      id: 'custom_provider',
      name: 'custom_provider',
      type: 'oauth',
      version: '2.0',
      scope: 'profile openid email',
      params: { grant_type: 'authorization_code' },
      accessTokenUrl: getAccessTokenUrl,
      requestTokenUrl: getAccessTokenUrl,
      authorizationUrl: `${getAccessCodeUrl}?response_type=code`,
      profileUrl: getProfileUtl,
      profile: async (profile: TProfile) => {
        return {
          id: profile.uid,
          role: profile.role,
          name: profile.displayName,
          email: profile.mail,
          position: profile.title
        };
      },
      clientId: CLIENT_ID,
      clientSecret: CLIENT_SECRET
    }
  ],
  debug: true,
  pages: {
    signIn: '/auth'
  },
  events: {},
  callbacks: {
    session: async (_session: any, token: any) => {
      return { ...token };
    },
    jwt: async (token: any, user: any, account: any) => {
      if (account && user) {
        const user = await getUser(account.accessToken);

        return {
          accessToken: account.accessToken,
          accessTokenExpires: getExpireTime(account.expires_in),
          refreshToken: account.refreshToken,
          user:
            'isAxiosError' in user ? { error: user.message || user.response?.data.message } : user
        };
      }

      if (!token.accessTokenExpires) return token;
      if (Date.now() < token.accessTokenExpires) return token;

      return refreshAccessToken(token);
    }
  }
};

export default (req: any, res: any) => {
  return NextAuth(req, res, options);
};

next server config:

const cacheableResponse = require('cacheable-response');
const express = require('express');
const next = require('next');
const dev = process.env.NODE_ENV !== 'production';
const hostname = '0.0.0.0';
const app = next({ dev });
const port = parseInt(process.env.PORT, 10) || 8080;

const handle = app.getRequestHandler();

app.prepare().then(() => {
  const server = express();

  server.all('*', (req, res) => handle(req, res))

  server.listen(port, hostname, err => {
    if (err) throw err;
    const host = dev ? 'localhost': hostname;
    console.log(`> Ready on http://${host}:${port}`);
  });
});

How to reproduce ☕️

The same config works well on other project with other custom provider, but completely on http.

There's no way I can lift encription (https -> http) currently, so I can't confirm this is the real reason.

[St-Permiakov]

Okay, it's solved.

The problem was in Basic authorisation, that was covering nginx.

If anyone else stumbles upon this problem, I think, either of this methods helps:

1. Disable Basic auth as soon as next-auth is up (we did just that).
2. Use NEXTAUTH_URL_INTERNAL for server calls with inner server DNS.

Discussion can be closed now.

[aboveyunhai]

For some reason I need to keep the basic authorization by nginx, so I chose the second options, which works out of box.

But I wonder why the problem occurs? And any risk if I used the private DNS?