nextauthjs / next-auth

Authentication for the Web.
https://authjs.dev
ISC License
22.7k stars 3.03k forks source link

Error: Invalid state returned from Google oAuth provider on production #656

Closed shrmaky closed 2 years ago

shrmaky commented 3 years ago

Hello everyone,

My Next-Auth application works completely fine when am running this in local environment, the redirection from google, and session registration in MongoDb is working fine,

When am trying to run the same application with same google id & secret in production, it is throwing Error: Invalid state returned from oAuth provider

_Already SET the valid NEXTAUTH_URL, DATABASE_URL, GOOGLE_ID & GOOGLESECRET

[next-auth][error][callback_oauth_error] Error: Invalid state returned from oAuth provider
    at /home/node/app/node_modules/next-auth/dist/server/lib/oauth/callback.js:46:27
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (/home/node/app/node_modules/next-auth/dist/server/lib/oauth/callback.js:26:103)
    at _next (/home/node/app/node_modules/next-auth/dist/server/lib/oauth/callback.js:28:194)
    at /home/node/app/node_modules/next-auth/dist/server/lib/oauth/callback.js:28:364
    at new Promise (<anonymous>)
    at /home/node/app/node_modules/next-auth/dist/server/lib/oauth/callback.js:28:97
    at /home/node/app/node_modules/next-auth/dist/server/lib/oauth/callback.js:143:17
    at /home/node/app/node_modules/next-auth/dist/server/routes/callback.js:58:31
    at Generator.next (<anonymous>)
https://next-auth.js.org/errors#callback_oauth_error

Feedback Documentation refers to searching through online documentation, code comments and issue history. The example project refers to next-auth-example.

iaincollins commented 3 years ago

Hmm we have seen folks run into this before.

  1. You might want to double / triple check the callback URLs for production specified in the app in Google.
  2. You might want to check the Client ID and Client Secret set in production.

I think at least one of these can cause that problem.

We really need to create a ticket to capture improving the debugging here before I forget about it again - if we logged the response at this point it would probably be saying what was wrong in the console.

glenarama commented 3 years ago

Im seeing the same issue - but only on first login of a session. Try immediately again and all is fine.

The error returns after logging in again after about an hour 24 hours, which i think is a new token.

JNussenzveig commented 3 years ago

Having the same issue here, but using Facebook provider. Any luck solving this yet?

JNussenzveig commented 3 years ago

Having the same issue here, but using Facebook provider. Any luck solving this yet?

Just found out that the problem was with a firebase import. Basically, it just requires firebase-admin, initializes using serviceAccount and exports admin.firestore()

I'm still trying to understand why this error is happening when using firebase-admin...

JNussenzveig commented 3 years ago

@shrmaky Double-check your [...nextauth] file, make sure none of the defined callback methods have errors. Try commenting the callbacks part, just to check if that works.

JNussenzveig commented 3 years ago

@shrmaky Double-check your [...nextauth] file, make sure none of the defined callback methods have errors. Try commenting the callbacks part, just to check if that works.

If you're using the serverless build target, try changing that to server, it did the trick in my case.

shrmaky commented 3 years ago

Thanks @JNussens i will try.

PAHHHBLO commented 3 years ago

@iaincollins

Hmm we have seen folks run into this before.

  1. You might want to double / triple check the callback URLs for production specified in the app in Google.
  2. You might want to check the Client ID and Client Secret set in production.

I think at least one of these can cause that problem.

We really need to create a ticket to capture improving the debugging here before I forget about it again - if we logged the response at this point it would probably be saying what was wrong in the console.

Hey I'm having this same issue.

I am convinced that the latest version of iOS or Safari for iOS broke authentication with Google. I've tested this an ungodly amount of times. I ONLY get this error when I try to login from an iPhone. I tested Android, Windows and Chrome in MacOS. It's all good. I'm absolutely positively sure that my code and callback URL's, Client ID and Secret are correct. Otherwise, I would not be able to login from any other device.

Here's my next-auth config.

[GET] /api/auth/callback/google?state=770d5...
12:41:07:32
Status: 302
Duration: 3.47ms
Memory Used: 126 MB
ID: gscxw-1607449...
User Agent:
Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Mobile/15E148 Safari/604.1
2020-12-08T17:41:07.367Z    20132d29-5534-4302-a619-da1d3...    ERROR   [next-auth][error][callback_oauth_error] Error: Invalid state returned from oAuth provider
    at /var/task/node_modules/next-auth/dist/server/lib/oauth/callback.js:46:27
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (/var/task/node_modules/next-auth/dist/server/lib/oauth/callback.js:26:103)
    at _next (/var/task/node_modules/next-auth/dist/server/lib/oauth/callback.js:28:194)
    at /var/task/node_modules/next-auth/dist/server/lib/oauth/callback.js:28:364
    at new Promise (<anonymous>)
    at /var/task/node_modules/next-auth/dist/server/lib/oauth/callback.js:28:97
    at /var/task/node_modules/next-auth/dist/server/lib/oauth/callback.js:143:17
    at /var/task/node_modules/next-auth/dist/server/routes/callback.js:58:31
    at Generator.next (<anonymous>) 
https://next-auth.js.org/errors#callback_oauth_error
anerror404 commented 3 years ago

i am facing the same problem. It happens randomly, most of the time everything works just fine and sometime it's not. I am using the same config.

PAHHHBLO commented 3 years ago

@anerror404 Are you using PWA with your app? I think that's what causing the issue. See here.

anerror404 commented 3 years ago

@anerror404 Are you using PWA with your app? I think that's what causing the issue. See here.

i am not using PWA. It works perfectly 95% of time i guess. Suddenly stop working when user try to login with facebook or google. Even sometime it works in one device and doesn't in another device at the same time. Sometimes i get this error when user click on the social login icon, sometimes when user clicks on the social login icon, choose the user account.

It's causing me serious problem as i m running an e-commerce site. People can't order without login.

PAHHHBLO commented 3 years ago

@anerror404 in #952 @martinatwainobicom provided a solution.

// [...nextauth].js
Providers.Google({
  clientId: process.env.NEXTAUTH_GOOGLE_ID,
  clientSecret: process.env.NEXTAUTH_GOOGLE_SECRET,
  state: false, // Disable the state feature
}),

It worked for me, but apparently, this opens a CSRF attacks vulnerability. I cannot advice you to use it because I don't know the implications of this solution.

This is what the documentation says about the state:

GET /api/auth/callback/:provider Handles returning requests from OAuth services during sign in. For OAuth 2.0 providers that support the state option, the value of the state parameter is checked against the one that was generated when the sign in flow was started - this uses a hash of the CSRF token which MUST match for both the POST and GET calls during sign in.

fiftie commented 3 years ago

I also had a problem with Google and Facebook providers not allowing me to log in from Safari on iOS. I'm not sure why, but I found out that it happens when I run the signIn('provider_name') function. I solved this problem with a classic implementation using form tags to work around it. Although it is a bit tedious, this should ensure security.

<form
  action={`${origin}api/auth/signin/google`}
  method="POST"
>
   <input type="hidden" name="csrfToken" value={csrfToken} />
   <input
     type="hidden"
     name="callbackUrl"
     value={origin}
   />
   <button type="submit">
      login google
   </button>
</form>
iaincollins commented 3 years ago

@fiftie Thanks for that detail, will look at that in the upcoming release and see if I can reproduce and if we can come up with a fix. The client should definitely be doing that automatically.

iaincollins commented 3 years ago

@returndiego

I am convinced that the latest version of iOS or Safari for iOS broke authentication with Google. I've tested this an ungodly amount of times. I ONLY get this error when I try to login from an iPhone. I tested Android, Windows and Chrome in MacOS. It's all good. I'm absolutely positively sure that my code and callback URL's, Client ID and Secret are correct. Otherwise, I would not be able to login from any other device.

I've only just seen this message! Thanks for the detail. That's really helpful.

It worked for me, but apparently, this opens a CSRF attacks vulnerability. I cannot advice you to use it because I don't know the implications of this solution.

Hey, that's great! Disabling state for a provider using state: false is fine in NextAuth.js, because of how we check URLs before redirecting, so this should be safe to do. We provide the option by default because it works for most clients and is ideal behaviour for RFC compliance; there are only 1 or 2 clients that actually require it to work.

I think how we are doing state has been refactored a bit in canary, so will be interesting to see if it resolves itself. If this fix resolves the issue on iOS though it's perfectly fine and I think we'd consider making it the default for Google if we can't get to the bottom of it.

I saw this as it was tagged in #1179 @timonweber and that's interesting and might be worth exploring. I wonder if there is something else about how Safari works on iOS that is triggering this and that we might need to look at.

Welcome feedback from anyone else who has run into this issue and if the suggested fix resolves it for them.

fiftie commented 3 years ago

@iaincollins In my environment, setting it to state: false did not improve the problem. Therefore, I used the aforementioned method to solve the problem.

Also, this problem was reproduced with 3.2.0-canary.10, so I suspect that the problem is different from state. I would like to fork the project and investigate the problem.

balazsorban44 commented 3 years ago

@fiftie I refactored state in canary (#1172) , could you check out the latest release? (the state property is still there, but going forward protection: state will be the recommended way)

af608 commented 3 years ago

@fiftie I refactored state in canary (#1172) , could you check out the latest release? (the state property is still there, but going forward protection: state will be the recommended way)

Hi @balazsorban44, I am seeing the same issue using the latest canary build [3.2.0-canary.35]. I added a comment with some more details here: (#1179)

fiftie commented 3 years ago

@iaincollins @balazsorban44 I apologize for the delay in testing. What I found out is that both 3.2.0-canary.35 and 3.1.0 have different problems.

3.2.0-canary.35

3.1.0

balazsorban44 commented 3 years ago

interesting. could you enable logging with the debug: true option and see if it tells anything useful?

yashSangai-birdeye commented 3 years ago

@returndiego

I am convinced that the latest version of iOS or Safari for iOS broke authentication with Google. I've tested this an ungodly amount of times. I ONLY get this error when I try to login from an iPhone. I tested Android, Windows and Chrome in MacOS. It's all good. I'm absolutely positively sure that my code and callback URL's, Client ID and Secret are correct. Otherwise, I would not be able to login from any other device.

I've only just seen this message! Thanks for the detail. That's really helpful.

It worked for me, but apparently, this opens a CSRF attacks vulnerability. I cannot advice you to use it because I don't know the implications of this solution.

Hey, that's great! Disabling state for a provider using state: false is fine in NextAuth.js, because of how we check URLs before redirecting, so this should be safe to do. We provide the option by default because it works for most clients and is ideal behaviour for RFC compliance; there are only 1 or 2 clients that actually require it to work.

I think how we are doing state has been refactored a bit in canary, so will be interesting to see if it resolves itself. If this fix resolves the issue on iOS though it's perfectly fine and I think we'd consider making it the default for Google if we can't get to the bottom of it.

I saw this as it was tagged in #1179 @timonweber and that's interesting and might be worth exploring. I wonder if there is something else about how Safari works on iOS that is triggering this and that we might need to look at.

Welcome feedback from anyone else who has run into this issue and if the suggested fix resolves it for them.

@iaincollins Using state: false did not help me in fixing the issue. However, after putting this value in provider whenever I do the login in Safari MacOS/iOS it again puts me back to signIn page, and the loop continues. Below is the options, I am using for the provider:

const options = {
  providers: [
    Providers.Google({
      clientId: process.env.NEXTAUTH_GOOGLE_ID,
      clientSecret: process.env.NEXTAUTH_GOOGLE_SECRET,
      state: false,
      authorizationUrl:
        "https://accounts.google.com/o/oauth2/v2/auth?prompt=consent&access_type=offline&response_type=code",
    }),
  ],
  jwt: {
    encryption: true,
    secret: process.env.JWT_SECRET,
    signingKey: process.env.SIGNING_KEY,
    encryptionKey: process.env.ENCRYPTION_KEY,
  },
};

PS:

alex-cory commented 3 years ago

Any updates on this?

znwhite commented 3 years ago

I'm having the same issue - can login fine on localhost:3000 but on my live link (hosted on vercel) I get redirected to my signup error page with error?error=Callback after correctly entering my google credentials. Adding state: false did not do anything to help unfortunately

balazsorban44 commented 3 years ago

Could someone from here check if modifying the cookies config as defined here: https://github.com/nextauthjs/next-auth/issues/1664#issuecomment-815285862 makes any difference?

shadowwalker commented 3 years ago

For folks using next-pwa, latest version should fix this problem for you

stale[bot] commented 2 years ago

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!

stale[bot] commented 2 years ago

Hi there! It looks like this issue hasn't had any activity for a while. To keep things tidy, I am going to close this issue for now. If you think your issue is still relevant, just leave a comment and I will reopen it. (Read more at #912) Thanks!

Ash-Kay commented 2 years ago

Issue for me was my site was accessible with both www and non-www, my NEXTAUTH_URL env variable didn't had www, so if someone access site with www there was issue in redirection, hence causing the error. Changed my NGINX config to redirect to non-www and it solved the issue.

donovanperalta commented 2 years ago

I was able to reproduce this issue in my production app, and it ended up being the same problem mentioned by @Ash-Kay in the previous comment. Every time I accessed the web app without using "www" in the URL, the OAuth error would be thrown. In the same way, if I logged in using the WWW domain, and then manually removed the "www" portion of the URL and reloaded the page, the NextAuth session would be dropped. Like in @Ash-Kay's case, I was able to make the changes to my Nginx config to redirect the non-WWW requests to the WWW domain.

rickitan commented 1 year ago

@Ash-Kay @donovanperalta Solved it by redirecting my www to non www version of my domain. Amazing insight, thank you so much guys!!!

subimage commented 1 year ago

Running into this same issue on Google Cloud Run. Site works great locally. Have added all production URLs into Google API page. Have even tried messing about with NEXTAUTH_URL_INTERNAL with no luck, thinking this was due to a vanity URL but Google Cloud calling different urls internally.