Google Provider TODO: Handle OIDC response body error

[INIRU]

Provider type

Google

Environment

 System:
    OS: macOS 14.4.1
    CPU: (11) arm64 Apple M3 Pro
    Memory: 127.47 MB / 18.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 21.7.3 - ~/.nvm/versions/node/v21.7.3/bin/node
    npm: 10.5.0 - ~/.nvm/versions/node/v21.7.3/bin/npm
  Browsers:
    Safari: 17.4.1
  npmPackages:
    @auth/mongodb-adapter: ^2.6.0 => 2.6.0 
    next: ^14.2.1 => 14.2.1 
    next-auth: ^5.0.0-beta.16 => 5.0.0-beta.16 
    react: ^18.2.0 => 18.2.0 

Reproduction URL

https://github.com/TodayWantLook/TWL-NextJS/tree/developer/iniru

Describe the issue

I seem to be having some issues getting the callbackurl from Google. I have attached the error in the picture above.

How to reproduce

//env.local

DB_NAME = DB_NAME
DB_URL = DB_URL

NEXTAUTH_URL = https://todaywantlook.vercel.app
AUTH_SECRET = secret

AUTH_GOOGLE_ID = ''
AUTH_GOOGLE_SECRET = ''

After making the above settings, you should see a prompt to check the Server Error Log when you arrive at the login page.

Expected behavior

The callbackurl should be routed correctly and you should be able to receive the login user information to the callbackurl normally.

[ndom91]

So I'm not 100% sure about this, but google is setup as an OIDC provider which will auto-detect all the required URLs from their .well-known oIDC manifest, but you've hardcoded the authorihzation URL.

You can pass the same additional parameters that yuo're appending like this:

 providers: [
   GoogleProvider({
     authorization: {
       params: {
         prompt: "consent",
         access_type: "offline",
         response_type: "code"
       }
     }
   })
 ],

In addition, you can drop the NEXTAUTH_URL environment variable. It should be auto-detected on Vercel. If that doesn't help, the up-to-date version is called AUTH_URL btw

[INIRU]

Oh, thank you for helping me with my code. I'll check it out.

[murilobd]

I'm running the app on AWS Amplify (not sure on how different is from Vercel) and I noticed that, when I pass the AUTH_REDIRECT_PROXY_URL env variable, it succeeds on the login/register but it still redirects to localhost:3000.

[INIRU]

So I'm not 100% sure about this, but google is setup as an OIDC provider which will auto-detect all the required URLs from their .well-known oIDC manifest, but you've hardcoded the authorihzation URL.

You can pass the same additional parameters that yuo're appending like this:

 providers: [
   GoogleProvider({
     authorization: {
       params: {
         prompt: "consent",
         access_type: "offline",
         response_type: "code"
       }
     }
   })
 ],

In addition, you can drop the NEXTAUTH_URL environment variable. It should be auto-detected on Vercel. If that doesn't help, the up-to-date version is called AUTH_URL btw

I tried the fix as you suggested, but it didn't fix the problem.
When I run it locally with npm run dev it logs in fine, but mysteriously when I push it up to the server, next-auth gives me an error.

[ndom91]

@INIRU can you share that next-auth error?

@murilobd the AUTH_REDIRECT_PROXY_URL option is designed for proxying preview deploy's through your prod deploy so you can login with Google (for example) on your preview deploys (or other apps), see: https://authjs.dev/getting-started/deployment#securing-a-preview-deployment

[ndom91]

@murilobd have yuo updated your callbackUrl in the Google / whatever OAUth provider dashboard? That's what tells the app where to redirect back to by default

[INIRU]

@ndom91

[GET][xxx] /api/auth/callback/google
error { error: 'invalid_client', error_description: 'Unauthorized' }

[GET][xxx] /api/auth/callback/google
[auth][error] CallbackRouteError: Read more at https://errors.authjs.dev#callbackrouteerror

[GET][xxx] /api/auth/callback/google
[auth][cause] Error: TODO: Handle OIDC response body error
    at ib (/var/task/.next/server/chunks/168.js:393:28075)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async iR (/var/task/.next/server/chunks/168.js:393:33995)
    at async iW (/var/task/.next/server/chunks/168.js:393:45324)
    at async iq (/var/task/.next/server/chunks/168.js:393:50193)
    at async /var/task/node_modules/next/dist/compiled/next-server/app-route.runtime.prod.js:6:34801
    at async eS.execute (/var/task/node_modules/next/dist/compiled/next-server/app-route.runtime.prod.js:6:25910)
    at async eS.handle (/var/task/node_modules/next/dist/compiled/next-server/app-route.runtime.prod.js:6:36055)
    at async ei (/var/task/node_modules/next/dist/compiled/next-server/server.runtime.prod.js:16:25466)
    at async es.responseCache.get.routeKind (/var/task/node_modules/next/dist/compiled/next-server/server.runtime.prod.js:17:1026)

[GET][xxx] /api/auth/callback/google
[auth][details]�[0m: {
  "provider": "google"
}

[GET][500] /api/auth/error
/api/auth/error?error=Configuration&nxtPnextauth=error status=500

[ndom91]

From that it seems like your clientId is either incorrect (copy and paste error maybe?) or just not being picked up. In order to infer it automatically, and not have to manually pass it to the Google() provider in your configuration, the environment variables have to be named like this:

AUTH_GOOGLE_ID
AUTH_GOOGLE_SECRET

Do you have that in place in your environment?

[murilobd]

@murilobd the AUTH_REDIRECT_PROXY_URL option is designed for proxying preview deploy's through your prod deploy so you can login with Google (for example) on your preview deploys (or other apps), see: https://authjs.dev/getting-started/deployment#securing-a-preview-deployment

Yes, I'm aware of that. But I thought maybe giving a try to bypass the "https://localhost:3000" and it worked partially. It stopped being redirected to localhost with queryParams error=Configuration (as it's happening with @INIRU )

@murilobd have yuo updated your callbackUrl in the Google / whatever OAUth provider dashboard? That's what tells the app where to redirect back to by default

Yes. I've triple checked the callbackUrl to be the good one (I even created a new credential without the localhost just to be sure).

What I've just tried was to set the redirect() callback and it's working fine when the login succeeds. But, when it fails (in case when the account is not linked with the oauth provider), it redirects to https://localhost:3000/login?error=OAuthAccountNotLinked

redirect({ url, baseUrl }) {
			const finalUrl = new URL(url, process.env.APP_URL || baseUrl).href;
			console.log(
				" ------------ xxxxxx redirect xxxxxxx --------------- ",
				"url: " + url,
				"baseUrl: " + baseUrl,
				"finalUrl: " + finalUrl
			);
			return finalUrl;
		}

The APP_URL is an env variable I created with the good hostname.
From the console.log, indeed, the baseUrl is being considered as https://localhost:3000

[murilobd]

@ndom91 just tried removing the AUTH_REDIRECT_PROXY_URL and it fails right after starting the auth process and redirects to: https://localhost:3000/api/auth/error?error=Configuration

[INIRU]

From that it seems like your clientId is either incorrect (copy and paste error maybe?) or just not being picked up. In order to infer it automatically, and not have to manually pass it to the Google() provider in your configuration, the environment variables have to be named like this:

AUTH_GOOGLE_ID
AUTH_GOOGLE_SECRET

Do you have that in place in your environment?

@ndom91
Yes, It's already set up and passes well to Google OAuth. The error seems to be in the CallbackRouting part.

[ndom91]

@murilobd the correct environment variable is AUTH_URL, give that a shot. The AUTH_REDIRECT_PROXY_URL may have avoided the initial error, but it enables a whoel different flow inside the core, it's not what you want. Please remove it and try AUTH_URL instead of APP_URL 🙏

EDIT: Also small sidenote, to get that log output it seems like yuo want, you can use console.table or add \n to the end of each line so the console.log prints a new line

[ndom91]

@ndom91 Yes, It's already set up and passes well to Google OAuth. The error seems to be in the CallbackRouting part.

Hmm well one way or another, google is telling us that the client_id it's receiving from you is invalid. I'd check the Google OAuth dashboard, maybe there's some more info there or in the worst case, I'd just generate a new clientId/clientSecret from Google

[murilobd]

The error seems to be in the CallbackRouting part.

I do suspect that's it too!

[INIRU]

my vercel env settings

[murilobd]

@murilobd the correct environment variable is AUTH_URL, give that a shot. The AUTH_REDIRECT_PROXY_URL may have avoided the initial error, but it enables a whoel different flow inside the core, it's not what you want. Please remove it and try AUTH_URL instead of APP_URL 🙏

@ndom91 When I set AUTH_URL, I have this error, simply by trying to access the webapp (and that's why I created the APP_URL)

[murilobd]

@ndom91 do you know if it's normal, when running the app on aws amplify, to have the network set as localhost?

I'm asking this because, maybe all the redirects to localhost are because of that?

[ndom91]

Yeah so that's the default thing your node process running next.js will expose. So your node process is running on a VM or container or whatever in Amplify and its exposing the applicaiotn at localhost:3000. Then Amplify will put a reverse proxy in front of that node process which will terminate and negotiate the SSL/TLS connection and accept traffic at https://app-123.aws.amplify.com (or whatever) and pass that traffic onto the node process in the container at localhost:3000. So yeah that part is fine 👍

But also, the fact that that reverse proxy is in the way, is why your application doesn't know anything about the final URL and you need to tell it via AUTH_URL. But also, that reminds me (!), you'll also need to enable the trustHost configuration option to tell next.js / auth.js to trust the URL that that reverse proxy tells the node process (via the X-Forwarded-Host header it appends to requests when handing the request off to the node process) (Docs)

So long story short, try also adding trustHost: true to your auth.js config, or adding the AUTH_TRUST_HOST=true env var to your environment

Sidenote: In real life there's multiple reverse proxies / load balancers / CDN's in between you and the node process running your node.js app in an AWS container in amplify or whatever.

[Nuno111]

Getting the same issue here.

I've got the same setup for github and google, github works fine but google gives me the invalid_client error and cause HANDLE OIDC response body error.

I've tripled checked, compared and searched by string, the clientId is 100% correct.

This is not new on my end, haven't been able to use google sign in since i setup next auth

[murilobd]

Yeah so that's the default thing your node process running next.js will expose. So your node process is running on a VM or container or whatever in Amplify and its exposing the applicaiotn at localhost:3000. Then Amplify will put a reverse proxy in front of that node process which will terminal SSL and accept traffic at https://app-123.aws.amplify.com (or whatever) and pass that traffic onto the node process in the container at localhost:3000. SO yeah that part is fine 👍

Thank you for the very clear explanation on how it works! I suspected it was, indeed, a reverse proxy, but just would like to confirm that authjs wasn't doing anything related to that.

So long story short, try also adding trustHost: true to your auth.js config, or adding the AUTH_TRUST_HOST=true env var to your environment

@ndom91 this is enabled. If I remove that configuration, I receive an error from authjs

[ndom91]

Hmm very weird, but that error object is coming from Google, so something seems wrong there as well. Maybe it's with what we send them, but the Google provider in our example app still works (https://next-auth-example.vercel.app/auth/signin) using [email protected].

Where that o.processAuthorizationCodeOpenIDResponse() is from panva's oauth4webapi library, see docs.

@Nuno111 Can you provide some more some more details about your setup? auth.ts configuration, versions of pkg and next, etc. 🙏

[Nuno111]

Sure thing @ndom91

Here's some screenshots with info

auth.ts callbacks has some logic, but when using google it doens't even reach the callbacks, for github all works fine, thats why i didn't bother showing that logic here

I've tried the trusthost: true in auth.ts but still getting same issue

[INIRU]

Strangely, it's been solved by recreating the Oauth ID.

[Nuno111]

Didn't fix it for me, same issue unfortunately!

[Nuno111]

@ndom91

I dug a little deeper and it seems the codeGrantResponse is not authorized before making the proccesAuthorizationCodeOpenIDResponse function call,

[ndom91]

@Nuno111 I see yuo're using [email protected], have you tried the latest -beta.17?

[murilobd]

On [email protected] I'm still facing the same issue, being redirected to https://localhost:3000 when authentication fails

[Nuno111]

@ndom91 @murilobd

Bumping to .17 solved my issue.

I then ran into another problem which you can find here #9922

But basically i changed my NEXTAUTH_URL to NEXTAUTH_URL_INTERNAL and now i'm able to use google auth

Thanks for the support!

[murilobd]

I'm still having the same issue as before when user cancel the authentication with google. Instead of being redirected to the correct URL, it redirects to https://localhost:3000.

Running on next 2.4, [email protected], prisma ^5.12.

Also, I'm using next-intl. Not sure if it plays a role in the bug I'm having, as I've mixed both in the middleware like that

import createIntlMiddleware from "next-intl/middleware";
import { auth as authMiddleware } from "./auth";
import { defaultLocale, locales } from "./i18n";

const intlMiddleware = createIntlMiddleware({
	locales,
	defaultLocale,
});

export default authMiddleware((req) => intlMiddleware(req));

export const config = {
	matcher: [
		"/((?!api|_next|favicon.ico|manifest.json|.*\\..*).*)",
	],
};

[codemaniac]

I'm facing the same issue using Auth0 as my provider and using @auth/sveltekit!
I'm using this sample project: https://github.com/nextauthjs/sveltekit-auth-example

Point to note: I see that the users are created in Auth0 - under User Management / Users

Tried reading through this thread to troubleshoot, but couldn't find anything useful! Please help!

Environment

 System:
    OS: Windows 11
    CPU: Core i7
  Binaries:
    Node: v20.12.2

package.json

"dependencies": {
    "@auth/sveltekit": "latest"
},

.env.local

AUTH_AUTH0_ID=123abc
AUTH_AUTH0_SECRET=xyz
AUTH_AUTH0_ISSUER=https://dev-abcdefg.us.auth0.com/
AUTH_SECRET=123456

src/auth.ts

import { SvelteKitAuth } from "@auth/sveltekit"
import Auth0 from "@auth/sveltekit/providers/auth0"


export const { handle, signIn, signOut } = SvelteKitAuth({
  trustHost: true,
  providers: [Auth0],
})

src/hooks.server.ts

export { handle } from "./auth"

Error Message

error { error: 'access_denied', error_description: 'Unauthorized' }
[auth][error] CallbackRouteError: Read more at https://errors.authjs.dev#callbackrouteerror
[auth][cause]: Error: TODO: Handle OIDC response body error
    at handleOAuth (file:///C:/.../sveltekit-auth-example-main/node_modules/@auth/core/lib/actions/callback/oauth/callback.js:86:19)
   .
   .
   .
[auth][details]: {
  "provider": "auth0"
}

Auth0 Settings

Application Login URI = <blank>
Allowed Callback URLs = http://localhost:5173/auth/callback/auth0
Allowed Logout URLs = http://localhost:5173
Allowed Web Origins = http://localhost:5173
Allowed Origins (CORS) = http://localhost:5173

P.S.: I've tried with the below package.json dependencies as well, but it still doesn't work

"dependencies": {
    "@auth/core": "latest",
    "@auth/sveltekit": "latest"
},

[min-stelland]

Yeah so that's the default thing your node process running next.js will expose. So your node process is running on a VM or container or whatever in Amplify and its exposing the applicaiotn at localhost:3000. Then Amplify will put a reverse proxy in front of that node process which will terminate and negotiate the SSL/TLS connection and accept traffic at https://app-123.aws.amplify.com (or whatever) and pass that traffic onto the node process in the container at localhost:3000. So yeah that part is fine 👍

But also, the fact that that reverse proxy is in the way, is why your application doesn't know anything about the final URL and you need to tell it via AUTH_URL. But also, that reminds me (!), you'll also need to enable the trustHost configuration option to tell next.js / auth.js to trust the URL that that reverse proxy tells the node process (via the X-Forwarded-Host header it appends to requests when handing the request off to the node process) (Docs)

So long story short, try also adding trustHost: true to your auth.js config, or adding the AUTH_TRUST_HOST=true env var to your environment

Sidenote: In real life there's multiple reverse proxies / load balancers / CDN's in between you and the node process running your node.js app in an AWS container in amplify or whatever.

This is the solution that worked for me. Thank you very much!

[tatleung]

My setup is as follows:

• Nginx webserver exposed to the public with HTTPS enabled.
• NextJS 15 application running on a different machine than the Nginx web server.
• Use Google for OAuth2 authentication
• next-auth 5.0.0-beta.19

I initially got the same error reported in this ticket. After I added AUTH_URL to .env.local with the value set to http://<web_server_host> and update the "Authorized redirect URIs" in Google to http://<web_server_host>/api/auth/callback/google, the problem does not occur anymore. Notice even though my web server is using HTTPS, I have to use HTTP for the redirect url. Using HTTPS did not work for me.

I have another application that is using next-auth 4. The "Authorized redirect URIs" I set there uses HTTPS. The webserver and NextJS app server setup for both applications are essentially identical. There seems to be some difference between Next-Auth 4 and 5.

BTW, when I configure the app using http://localhost:3000 (not using webserver reverse proxy), it is also working correctly. Hope this helps someone.

Also, I also enabled GitHub authentication. For it, I had to set the AUTH_URL to use HTTPS. There seems to be an issue with Google authentication.

[mahbd]

I don't know how and why but in my case it got solved after changing AUTH_SECRET.

My project was running just fine in local machine but was not working in vercel. Then I copied my local machine AUTH_SECRET and now it is working. Maybe AUTH_SECRET was badly formatted or something else I don't know.

[mariomeissner]

Leaving a note here for others just in case it's helpful.

I had a functioning auth setup with "next-auth": "5.0.0-beta.19" deployed on Vercel.
When I moved to Railway, the issue described in this ticket started happening. The likely explanation is the way that Railway exposes the endpoint via proxy, such that it thinks it should use localhost when in fact it should be using the public domain URL.

Setting NEXT_AUTH=https://my-website.com/api/auth/ in Railway fixed the issue for me!

[zhm]

I just spent way too long troubleshooting this Error: TODO: Handle OIDC response body error error and the problem ended up being I missed a double quote in the env file for the AUTH_GOOGLE_SECRET value at the end. Face palm!