-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Google Provider TODO: Handle OIDC response body error #10731
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
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 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 |
Oh, thank you for helping me with my code. I'll check it out. |
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. |
I tried the fix as you suggested, but it didn't fix the problem. |
@INIRU can you share that next-auth error? @murilobd the |
@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 |
[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 |
From that it seems like your
Do you have that in place in your environment? |
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 )
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
The |
@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 |
@ndom91 |
@murilobd the correct environment variable is EDIT: Also small sidenote, to get that log output it seems like yuo want, you can use |
Hmm well one way or another, google is telling us that the |
I do suspect that's it too! |
@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) |
@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 |
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 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 So long story short, try also adding 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. |
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.
@ndom91 this is enabled. If I remove that configuration, I receive an error from authjs |
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 Where that @Nuno111 Can you provide some more some more details about your setup? |
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 ![]() ![]() ![]() ![]() |
Strangely, it's been solved by recreating the Oauth ID. |
Didn't fix it for me, same issue unfortunately! |
@Nuno111 I see yuo're using |
On |
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, next-auth@5.0.0-beta.17, 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
|
I'm facing the same issue using Point to note: I see that the users are created in Tried reading through this thread to troubleshoot, but couldn't find anything useful! Please help! Environment
package.json
.env.local
src/auth.ts
src/hooks.server.ts
Error Message
Auth0 Settings
P.S.: I've tried with the below package.json dependencies as well, but it still doesn't work
|
This is the solution that worked for me. Thank you very much! |
My setup is as follows:
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. |
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. |
Leaving a note here for others just in case it's helpful. I had a functioning auth setup with Setting |
Provider type
Google
Environment
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
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.
The text was updated successfully, but these errors were encountered: