Manually Test Providers (v4)

ubbe-xyz commented 3 years ago

Description 📓

Before the release of v4 we want to manually test most (if not all) the current OAuth providers to make sure the changes that happen on v4 to their configuration didn't break any of them 🤞🏽

We also haven't enforced any kind of testing prior to v4, so there is a big chance that some providers do not even work in v3, which might have gone undetected if there was no interest from users to open issues.

Here's the table where we keep track of this testing:

Provider	Account created	Manually tested	Comments
`42`	✅	✅	#3189, tested by @estarossa0
`Apple`	✅	✅	#2875. Thanks @sergeymishin and @TheoBr for the help! See https://github.com/nextauthjs/next-auth/pull/2875#issue-747917222 for caveats
`Atlassian`	✅	🚨	Not able to redirect back to `callback_url`, internal error at Atlassian
`Auth0`	✅	✅
`Azure B2C`	✅	✅	#2862, @BenjaminWFox provided me test account/client. We could not retrieve a profile picture
`Azure AD`	✅	✅	Fixed in #2818, @ndom91 has the account for this to test. Default profile picture size is 64x64 #2910
~`Basecamp`~	❌	❌	Removed see, https://github.com/nextauthjs/next-auth/pull/511#issuecomment-892079767
`BattleNet`	N/A
`Box`	N/A
`Bungie`
`Cognito`	✅	✅	#2829, AWS provided by @s-kris
`Coinbase`	N/A
`Discord`	✅	✅
`Dropbox`	✅
`Eve Online`
`Facebook`	✅	✅
`FaceIT`	✅
`FourSquare`	✅	✅
`Freshbooks`	✅
`FusionAuth`		✅	#3376 by @alessandrojcm
`Github`	✅	✅
`Gitlab`	✅	✅
`Google`	✅	✅
`IS4`	✅	✅
`Instagram`	✅
`Kakao`	✅
`Keycloak`	✅	✅	#2485, #2851
`Line`	✅	✅	#2917, email needs special setup. tested by @ThangHuuVu
`LinkedIn`	✅	✅	#2821
`MailChimp`	✅
`MailRu`
`Medium`
`Naver`
`Netlify`
`Okta`	✅	✅	#2856
`OneLogin`	✅	✅
`Osso`
`Reddit`
`Salesforce`
`Slack`	✅	✅	Fixed in #2848. Requires `https` for redirect URLs, even for local development. Used `ngrok`
`Spotify`	✅	✅
`Strava`
`Twtich`	✅	✅
`Twitter`	✅	✅
`VK`
`Wordpress`
`WorkOS`	✅	✅	WIP #3886 thanks @m-abdelwahab for the infra support
`Yandex`
`Zoho`
`Zoom`

@balazsorban44 @ndom91 if you could mark the ones you have already manually tested and verified they're working so we can know which ones are left to test 🙏🏽

Notes

BattleNet requires Battle.net Authenticator (possibly replaceable via their first-party app. This is different from normal TOTP)
Box only has paid plans
Coinbase requires to know your customer (KYC) verification via video chat like when opening a bank account

The relevant PR making this required is #2411. Checks its description for more info.

The documentation page here might also be useful: https://next-auth.js.org/configuration/providers/oauth-provider#options

ndom91 commented 3 years ago

Made some updates and wrote notes regarding providers that will be difficult / impossible for us to manually test.

I'll manually try some of the additional ones for which we have clientId's / secrets soon :+1:

balazsorban44 commented 3 years ago

Anyone reading this, if you use any of the built-in providers, we would highly appreciate your help making sure that those will work in the future! Until now, we haven't enforced anything at all, and so some built-in providers might have never even worked properly...

Please leave a comment here if you find an issue or have anything related to say! :pray: :green_heart:

inu4g0t commented 3 years ago

Hi, @lluia . I'm trying to integrate nextjs with azure ad. I found it always report "Insufficient privileges" with 403 on getting the user.

After detailed check, I think the issue is at auth step where to "scope" is always set to "openid" rather than the one defined in doc which should be 'offline_access User.Read' From the debug, the auth scope 'openid' is coming from https://github.com/panva/node-openid-client/blob/main/lib/client.js function authorizationParams(params) { const authParams = { client_id: this.client_id, scope: 'openid', response_type: resolveResponseType.call(this), redirect_uri: resolveRedirectUri.call(this), ...params, };

This scope 'openid', the get user function does not have enough permission to retrive user information with graph api /me and always generate 403.

I'm not expert on either aad or next-auth so I can hardly sure if this is a bug or something wrong with my setting but I have tried to force the scope to 'offline_access User.Read' which makes it work.

javigonz commented 3 years ago

Hi @lluia, I´m trying to upgrade Next-auth v4.0.0-beta.2 with CognitoProvider. Passing an empty string in clientSecret parameter, return an error message.

import NextAuth from 'next-auth';
import CognitoProvider from 'next-auth/providers/cognito';

export default NextAuth({
  providers: [
    CognitoProvider({
      clientId: process.env.COGNITO_CLIENT_ID,
      clientSecret: '',
      domain: process.env.COGNITO_DOMAIN,
      issuer: `https://${process.env.COGNITO_DOMAIN}/`
    })
  ],
  callbacks: {...}
});

message: 'client_secret_basic client authentication method requires a client_secret',

After a little research, this error is not in your library, it is due to a dependence library "openid-client": "^4.7.4". I´ve just opened an issue where I explain the situation. https://github.com/panva/node-openid-client/issues/402

panva commented 3 years ago

@javigonz you should set the client's token endpoint auth method to none, not your client secret to an empty string. That's the very much intended state.

Whether next-auth abstracts setting the method to none for you or exposes a client auth property is out of openid-client Lin's control.

javigonz commented 3 years ago

Yeah @panva, probably that the key, add a way to set this token endpoint auth method into https://next-auth.js.org/configuration/providers/oauth-provider#options

balazsorban44 commented 3 years ago

Going to expose further options through #2717, I'll just test it out locally.

balazsorban44 commented 3 years ago

@javigonz could you test out? https://github.com/nextauthjs/next-auth/pull/2717#issuecomment-917213302

Check the new client option

taep96 commented 3 years ago

Hi, @lluia . I'm trying to integrate nextjs with azure ad. I found it always report "Insufficient privileges" with 403 on getting the user.

After detailed check, I think the issue is at auth step where to "scope" is always set to "openid" rather than the one defined in doc which should be 'offline_access User.Read' From the debug, the auth scope 'openid' is coming from https://github.com/panva/node-openid-client/blob/main/lib/client.js function authorizationParams(params) { const authParams = { client_id: this.client_id, scope: 'openid', response_type: resolveResponseType.call(this), redirect_uri: resolveRedirectUri.call(this), ...params, };

This scope 'openid', the get user function does not have enough permission to retrive user information with graph api /me and always generate 403.

I'm not expert on either aad or next-auth so I can hardly sure if this is a bug or something wrong with my setting but I have tried to force the scope to 'offline_access User.Read' which makes it work.

Having same issue

mckernanin commented 3 years ago

Testing the EVE Online integration, I receive the following error from EVE's login server:

{
"error": "invalid_scope",
"error_description": "The requested scopes either don't exist, or are not valid for this client"
}

If I update the scope in the URL to publicData then the EVE login succeeds. I added an authorization object like this, but I'm still having the same issue.

    EVEOnlineProvider({
      clientId: config.esiId,
      clientSecret: config.esiSecret,
      authorization: { params: {scope: 'publicData'}}
    })

After investigating further and testing myself, I got it working with an updated provider where I specified the authorization property in the default parameters for the provider. I opened a PR with these changes, where I also rewrote the EVE Provider in TypeScript.

idac73 commented 2 years ago

Hi! Thanks so much for what is shaping up to be an excellent library.

I'm testing 4.0.0-beta.2 using the AzureADProvider and the profile.user is undefined, which may be rooted in an error at line 149 ./server/lib/oauth/callback.js when attempting profile.id.toString() for the providerAccountId property. Hacking this property to use OAuthProfile.sub and running with debug: true outputs fully populated OAuthProfile and account objects. The profile object from the OAUTH_CALLBACK_RESPONSE is profile: { id: undefined, name: undefined, email: undefined, image: null }

I first referenced the documentation for this provider, but using this config provided a successful response for me:

    AzureADProvider({
      authorization: {
        params: {
          audience: process.env.AZURE_AD_CLIENT_ID,
          response_mode: 'form_post',
          response_type: 'code id_token',
          scope: 'offline_access openid profile email User.Read'
        }
      },
      clientId: process.env.AZURE_AD_CLIENT_ID,
      clientSecret: process.env.AZURE_AD_CLIENT_SECRET,
      tenantId: process.env.AZURE_AD_TENANT_ID,
      wellKnown: process.env.AZURE_AD_OPENID
    })

taep96 commented 2 years ago

AzureADProvider({
  authorization: {
    params: {
      audience: process.env.AZURE_AD_CLIENT_ID,
      response_mode: 'form_post',
      response_type: 'code id_token',
      scope: 'offline_access openid profile email User.Read'
    }
  },
  clientId: process.env.AZURE_AD_CLIENT_ID,
  clientSecret: process.env.AZURE_AD_CLIENT_SECRET,
  tenantId: process.env.AZURE_AD_TENANT_ID,
  wellKnown: process.env.AZURE_AD_OPENID
})

URL still only has openid for me

jerptrs commented 2 years ago

Testing now next-auth@4.0.0.-beta.2, I'm trying to set a different scope for various providers.

import NextAuth from 'next-auth';
import DiscordProvider from 'next-auth/providers/discord';
import TwitchProvider from 'next-auth/providers/twitch';

export default NextAuth({
  providers: [
    DiscordProvider({
      clientId: process.env.DISCORD_CLIENT_ID,
      clientSecret: process.env.DISCORD_CLIENT_SECRET,
      authorization: {
        params: {
          scope: 'email connections identity activities.read',
        },
      },
    }),
    TwitchProvider({
      clientId: process.env.TWITCH_CLIENT_ID,
      clientSecret: process.env.DISCORD_CLIENT_SECRET,
      authorization: {
        params: {
          scope: 'user:read:email user:read:follows',
        },
      },
    }),
  ],
});

Unfortunately overwriting the default parameters isn't working for me.

balazsorban44 commented 2 years ago

@jerptrs You have a typo in discord

https://discord.com/developers/docs/topics/oauth2#shared-resources-oauth2-scopes

the scope is called identify, not identity.

In both cases, you might have to look at the profile callback as well. They only return a subset by default.

jerptrs commented 2 years ago

@balazsorban44 oh boi. Thanks, that fixed it.

Patryks1 commented 2 years ago

@balazsorban44 oh boi. Thanks, that fixed it.

Are the scopes being added in your generated URL? and if not have you encountered this error ? - message: "Cannot read property 'charAt' of undefined",

Profile is returned correctly + added to the DB but the CB fails.

I have the same setup as you, It seems like identify and email are hard coded into the auth discord url in the provider - https://github.com/nextauthjs/next-auth/blob/beta/src/providers/discord.js

@balazsorban44 Is that intended? seems like in v3.9 it was not included - https://github.com/nextauthjs/next-auth/blob/main/src/providers/discord.js

 DiscordProvider({
      clientId: process.env.DISCORD_CLIENT_ID,
      clientSecret: process.env.DISCORD_CLIENT_SECRET,
      authorization: {
        params: {
          scope: 'email connections identify activities.read',
        },
      },
    }),

Using this setup it does not tag on connections and activities.read to the scope.

Using v4.0.0.beta2

balazsorban44 commented 2 years ago

Good findings about Azure AD at https://github.com/nextauthjs/next-auth/discussions/2690

idac73 commented 2 years ago

TY @balazsorban44 👏 - The profile mapping in the config provided by @panigrah was exactly what I needed in my AzureADProvider

gabriel-ayusso commented 2 years ago

Hi guys!

I'm trying to use next-auth v4b with Identity Server 4, but without success.... When I use sample configuration with demo.identityserver.io, nothing happens when I click on login button. In the Url changes to http://localhost:3000/api/auth/signin?csrf=true, and it doesn't redirects do IS.

Could you please check if I'm doing something wrong?

Thank you in advance!

My provider configuration is:

export default NextAuth({
   providers: [
      IdentityServer4Provider({
         id: "demo-identity-server",
         name: "Demo IdentityServer4",
         authorization: { params: { scope: "openid profile email api offline_access" } },
         issuer:  "https://demo.identityserver.io/",
         clientId: "interactive.confidential",
         clientSecret: "secret",
       })
   ]
})

// _app.tsx
function MyApp({ Component, pageProps: { session, ...pageProps } }: AppProps) {
   return (
      <SessionProvider session={pageProps.session}>
         <Component {...pageProps} />
      </SessionProvider >
   );
}
export default MyApp

// index.tsx
const Home: NextPage = () => {
   const { data: session } = useSession()
   if (session) {
     return (
       <>
         Signed in as {session.user?.email} <br />
         <button onClick={() => signOut()}>Sign out</button>
       </>
     )
   }
   return (
     <>
       Not signed in <br />
       <button onClick={() => signIn()}>Sign in</button>
     </>
   )
}

export default Home

balazsorban44 commented 2 years ago

I verified IS4 already, so please rather open a question in the Discussions. Seems to be a user-specific problem.

Thisen commented 2 years ago

I verified IS4 already, so please rather open a question in the Discussions. Seems to be a user-specific problem.

I'm also facing issues with IS4 - It looks like the user object is null when logging in. I've tried calling the userinfo endpoint from .wellknown manually, which responds with the correct userinfo.

balazsorban44 commented 2 years ago

I reached out on Twitter for support on getting to set up a Cognito and Azure AD app for testing. https://twitter.com/balazsorban44/status/1440403111357468672

Please retweet, or reach out to me if you or your company could help us! :pray:

lolJS commented 2 years ago

Testing Cognito now. It's definitely broken. It tries to use issuer for authorization and that doesn't work. You can work around by setting issuer = to https + domain, but then you get an issuer mismatch later. Not sure if this is a fix on the provider side or the next-auth side.

balazsorban44 commented 2 years ago

@lolJS I would like to have a look/fix Cognito, but I don't have access to a Cognito app yet. 😅

kevin-dsouza commented 2 years ago

@balazsorban44 I was able to successfully manually test Cognito provider with next-auth version v4.0.0-beta.2. I would recommend renaming COGNITO_ISSUER to COGNITO_DOMAIN (as its less confusing) and users need to make sure theres a forward slash at the end of the url they enter eg COGNITO_ISSUER=https://xyz.auth.us-west-2.amazoncognito.com/

balazsorban44 commented 2 years ago

We use issuer because it is something that is present in the OAuth 2.0 spec, while domain is not:

https://tools.ietf.org/id/draft-ietf-oauth-discovery-08.html#ASMetadata

Once I get hold of a Cognito app, I'll try to fix the default config.

Thisen commented 2 years ago

@balazsorban44 @gabriel-ayusso, I got Identity-server4 to work with next-auth v4 with the following config:

IdentityServer4Provider({
  authorization: { params: { scope: "openid profile email api offline_access" } },
  issuer: "https://demo.identityserver.io",
  clientId: "interactive.confidential",
  clientSecret: "secret",
  version: "2.0",
  idToken: false,
})

lolJS commented 2 years ago

@balazsorban44 I can give you access to my app. Let me know what the best way would be to share creds.

balazsorban44 commented 2 years ago

Azure AD is now fixed. @ndom91 and I tested it locally, see #2818

Will be out in the next beta. I don't have an ETA, will look at other providers first and release them when we have some more.

balazsorban44 commented 2 years ago

Thanks, @lolJS! :pray: Could you write me on Twitter, or an e-mail to discuss?

balazsorban44 commented 2 years ago

Cognito is fixed in #2829

mshndev commented 2 years ago

Hi guys!

I'm testing 4.0.0-beta.2 using the AppleProvider with the default config:

import AppleProvider from "next-auth/providers/apple";
export default NextAuth({
  providers: [
    AppleProvider({
      clientId: process.env.APPLE_ID,
      clientSecret: {
        teamId: process.env.APPLE_TEAM_ID,
        privateKey: process.env.APPLE_PRIVATE_KEY,
        keyId: process.env.APPLE_KEY_ID
      }
    }),
    ...

Which causes TypeError: Cannot read property 'url' of undefined at line 23 of next-auth/server/lib/oauth/client.js trying to access provider.userinfo.url property

Apple provider worked for me on a stable version of next-auth, so I checked the previous version of providers/apple.js found that profileUrl: null, tried to add userinfo: {} to the config, and that error has gone.

Then I'm faced with OPError: invalid_client error from the openid-client fetching the oauthCallback from line 89 of next-auth/server/lib/oauth/callback.js

Same thing with a pre-generated client secret.

I see that openid-client is using Authorization: Bearer ... header instead of client_id and client_secret params in the request body of https://appleid.apple.com/auth/token (according to Apple docs)

...

I spent a couple of hours figuring out how to fix that and came up with this config:

AppleProvider({
  issuer: 'https://appleid.apple.com', // to avoid "unexpected iss value" error
  clientId: process.env.APPLE_ID,
  clientSecret: appleSecret, // pre-generated JWT, clientSecret object doesn't work
  userinfo: {}, //  to fix "Cannot read property 'url' of undefined" error
  idToken: true, // next-auth/server/lib/oauth/callback.js:81 provider.idToken not provider.token.idToken
  token: {
    url: "https://appleid.apple.com/auth/token",
    request: async ({provider, params, checks, client}) => {
      // Add client_id and client_secret params to the request body
      const exchangeBody = {
        client_id: provider.clientId,
        client_secret:  provider.clientSecret
      }

      return {
        tokens: await client.callback(provider.callbackUrl, params, checks, {exchangeBody})
      }
    }
  }
})

But to avoid the jwks_uri must be configured on the issuer error from openid-client I also added jwks_uri: provider.jwks_endpoint option in next-auth/server/lib/oauth/client.js (the jwks_endpoint is already defined on default AppleProvider params).

issuer = new Issuer({
  issuer: provider.issuer as string,
  jwks_uri: provider.jwks_endpoint, // to fix https://next-auth.js.org/errors#callback_oauth_error jwks_uri must be configured on the issuer
  authorization_endpoint: provider.authorization.url,
  token_endpoint: provider.token.url,
  userinfo_endpoint: provider.userinfo.url,
})

Hope that helps

balazsorban44 commented 2 years ago

Thanks, @sergeymishin! As far as I am aware, to register a client with Apple, I have to pay for an Apple Developer account or something similar. I am currently trying to figure out how to avoid that. :sweat_smile: If you or your company would be willing to set up a test client for us with a single user, that would help tremendously, and I could probably fix the AppleProvider in no time, to work with minimal configuration. openid-client is our new underlying OAuth library which takes security and specs much more seriously, and is regularly updated, hence the choice.

@s-kris was so kind to provide us the infrastructure to fix the Cognito provider, and we could certainly put you in the https://github.com/nextauthjs/next-auth/tree/beta#support section if you could help :pray:

Until I can test the provider locally myself, your userland implementation might be the best solution.

mshndev commented 2 years ago

@balazsorban44 I emailed you about creating a test Apple client

deadcoder0904 commented 2 years ago

Not sure why you guys are manually testing? Why not setup E2E?

If anything breaks in the future, you will know instantly. See https://twitter.com/mxstbr/status/1371828851811172359 & https://twitter.com/mxstbr/status/1371831260746821639

balazsorban44 commented 2 years ago

You can think of our manual testing as "e2e" tests. The reason for doing this manually is that the conversion from v3 to v4 is a manual task in itself since we changed the underlying OAuth library that has a much stricter interpretation of the OAuth spec (which is a good thing for security amongst other things).

Setting up tests that run in CI/CD would be ideal, but isn't possible for our use case. Most OAuth providers won't allow logging in from cloud IPs (like Github Actions), and even then, you would randomly have to provide a verification code sent to a phone number/email address (2FA), which we cannot mitigate very well. All in all, it is not so strange that these providers' bot detection try to detect that we would log in with a bot. 🙃

If you have any other advice to make testing smoother though, I would like to hear it!

deadcoder0904 commented 2 years ago

If you have any other advice to make testing smoother though, I would like to hear it!

Naah, that makes sense!

slavabez commented 2 years ago

Hi everyone.

Working on a new project, ran into issues with 2 providers, here are the details.

export default NextAuth({
  debug: true,
  secret: process.env.NEXTAUTH_SECRET,
  adapter: PrismaAdapter(client),
  providers: [
    Email({
      server: process.env.EMAIL_SERVER,
      from: process.env.EMAIL_FROM,
      maxAge: 60 * 60,
      sendVerificationRequest: sendLoginEmail,
    }),
    Yandex({
      clientId: process.env.YANDEX_ID,
      clientSecret: process.env.YANDEX_SECRET,
    }),
    VK({
      clientId: process.env.VK_ID,
      clientSecret: process.env.VK_SECRET,
    }),
    MailRu({
      clientId: process.env.MAILRU_ID,
      clientSecret: process.env.MAILRU_SECRET,
    }),
  ],
});

I created brand new accounts for each one of them, then configured new apps.

I can confirm he Yandex provider works well.

The error I get with VK (CALLBACK_OAUTH_ERROR):

error: {
    message: 'invalid_client (client_id is undefined)',
    providerId: 'vk',
    message: 'invalid_client (client_id is undefined)'
}

The error I get with Mail.ru (OAUTH_CALLBACK_RESPONSE):

OAuthProfile: {
    error: 'invalid request',
    error_code: 2,
    error_description: 'missing request parameter: access_token',
    user: null
  },

Please let me know how I can help, I can help submit a PR, but I'm unsure how to fix the issues. Is there a way to debug provider callbacks?

jimmy-grande commented 2 years ago

Hi everyone,

I am using next-auth 4.0.0-beta.4 with AzureADProvider and want to report an issue. When image profile is heavy, I have the following warning and authentication is not performed (no error message)

Set-Cookie header is ignored in response from url: http://localhost:3000/api/auth/callback/azure-ad?code=xxx&state=yyy&session_state=zzz. Cookie length should be less than or equal to 4096 characters.

I had to fix it by overriding the profile function with this

async profile(profile, tokens) {
        // https://docs.microsoft.com/en-us/graph/api/profilephoto-get?view=graph-rest-1.0#examples
        const profilePicture = await fetch("https://graph.microsoft.com/v1.0/me/photos/64x64/$value", {
          headers: {
            Authorization: `Bearer ${tokens.access_token}`,
          },
        });
        const pictureBuffer = await profilePicture.arrayBuffer();
        const pictureBase64 = Buffer.from(pictureBuffer).toString("base64");
        return {
          id: profile.sub,
          name: profile.name,
          email: profile.email,
          image: `data:image/jpeg;base64, ${pictureBase64}`,
        };
      }

I've just changed the profilePicture url by replacing https://graph.microsoft.com/v1.0/me/photo/$value with https://graph.microsoft.com/v1.0/me/photos/64x64/$value

Should we set a default size to avoid that kind of issue?

balazsorban44 commented 2 years ago

Good catch! Yeah, I guess we can do that. Care to open a PR against beta? We should probably mention this as a potential error in the docs. https://github.com/nextauthjs/docs/issues/62

Have you tested with a 128x128 size? 64x64 might be a bit too small, what do you think? Is there anything in between? As long as we document it, I am fine with any size TBH.

ThangHuuVu commented 2 years ago

Hi, I tested Line OAuth, and it is not working. The error is as follow:

[next-auth][error][OAUTH_CALLBACK_ERROR] 
https://next-auth.js.org/errors#oauth_callback_error userinfo sub mismatch, expected <MY USER ID>, got: undefined {
  error: {
    message: 'userinfo sub mismatch, expected <MY USER ID>, got: undefined',
    stack: 'RPError: userinfo sub mismatch, expected <MY USER ID>, got: undefined\n' +
      '    at Client.userinfo (/Users/lw70972/repos/github/next-auth/node_modules/openid-client/lib/client.js:1160:15)\n' +
      '    at runMicrotasks (<anonymous>)\n' +
      '    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n' +
      '    at async oAuthCallback (webpack-internal:///../src/server/lib/oauth/callback.ts:124:17)\n' +
      '    at async Module.callback (webpack-internal:///../src/server/routes/callback.js:52:11)\n' +
      '    at async NextAuthHandler (webpack-internal:///../src/server/index.ts:186:18)\n' +
      '    at async eval (webpack-internal:///../src/server/index.ts:273:32)\n' +
      '    at async Object.apiResolver (/Users/lw70972/repos/github/next-auth/app/node_modules/next/dist/server/api-utils.js:101:9)\n' +

      '    at async DevServer.handleApiRequest (/Users/lw70972/repos/github/next-auth/app/node_modules/next/dist/server/next-server.js:770:9)\n' +
      '    at async Object.fn (/Users/lw70972/repos/github/next-auth/app/node_modules/next/dist/server/next-server.js:661:37)',
    name: 'RPError'
  },
  providerId: 'line',
  message: 'userinfo sub mismatch, expected <MY USER ID>, got: undefined'
}

Where MY USER ID is this value in Line Developer Console:

This is reproducible on the beta branch, with the base setup:


export default NextAuth({
  providers: [
    LineProvider({
      clientId: process.env.LINE_ID,
      clientSecret: process.env.LINE_SECRET,
    }),
  ]

I can also reproduce it on my app, same setup and same error. I'll be happy to help with a PR if you can point me in the right direction for the fix.

jimmy-grande commented 2 years ago

Good catch! Yeah, I guess we can do that. Care to open a PR against beta? We should probably mention this as a potential error in the docs. nextauthjs/docs#62

Have you tested with a 128x128 size? 64x64 might be a bit too small, what do you think? Is there anything in between? As long as we document it, I am fine with any size TBH.

Based on Microsoft documentation, here is the following sizes:

The supported sizes of HD photos on Microsoft 365 are as follows: 48x48, 64x64, 96x96, 120x120, 240x240, 360x360, 432x432, 504x504, and 648x648. Photos can be any dimension if they are stored in Azure Active Directory.

I've tried with 96x96 and it did not work.

mshndev commented 2 years ago

There's one more problem with the Apple provider: after sign in it always redirects to the root URL of the app, ignoring the callbackUrl param. It works fine with Google provider though.

balazsorban44 commented 2 years ago

don't think it's v4 related, I think this came up before check the old issues maybe, I cannot right now

nikitalk commented 2 years ago

Hi! I've tested VK, MailRu and Yandex. Yandex is working well. VK and MailRu are not working. Error for VK: 2021-10-13 Error for MailRu: 2021-10-13 (1)

hckhanh commented 2 years ago

Hi @balazsorban44 @lluia For Atlassian provider, I figured out the problem. It came from the authorization url.

https://auth.atlassian.com/oauth/authorize?client_id=client_id&scope=offline_access%20read%3Ame&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fapi%2Fauth%2Fcallback%2Fatlassian&audience=api.atlassian.com&prompt=consent&state=f1ab2d629f610a5237895586a8f4512d7317f4ff98145ba30359f6b5255e0170

It must be

https://auth.atlassian.com/authorize?<the rest of url>

The /oauth prefix of the uri is incorrect.

ndom91 commented 2 years ago

~@hckhanh good catch! Opened a PR for this here: https://github.com/nextauthjs/next-auth/pull/3000/files~ Whoops didn't see your existing one haha

benedfit commented 2 years ago

Having issues with the Bungie provider when trying to upgrade to v4:

headers: { 'X-API-Key': provess.env.BUNGIE_API_KEY }, which was used in v3, and still referenced in the docs can no longer be set

When trying to test the Bungie provider the following error is now thrown:

https://next-auth.js.org/errors#oauth_callback_handler_error invalid_scope {
error: {
message: 'invalid_scope',
stack: 'Error: invalid_scope\n' +
  '    at oAuthCallback (/Users/benedfit/Projects/newhighsco/destiny-clan-warfare/node_modules/next-auth/core/lib/oauth/callback.js:37:19)\n' +
  '    at Object.callback (/Users/benedfit/Projects/newhighsco/destiny-clan-warfare/node_modules/next-auth/core/routes/callback.js:50:39)\n' +
  '    at NextAuthHandler (/Users/benedfit/Projects/newhighsco/destiny-clan-warfare/node_modules/next-auth/core/index.js:103:41)\n' +
  '    at runMicrotasks (<anonymous>)\n' +
  '    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n' +
  '    at async NextAuthNextHandler (/Users/benedfit/Projects/newhighsco/destiny-clan-warfare/node_modules/next-auth/next/index.js:40:7)\n' +
  '    at async /Users/benedfit/Projects/newhighsco/destiny-clan-warfare/node_modules/next-auth/next/index.js:80:32\n' +
  '    at async Object.apiResolver (/Users/benedfit/Projects/newhighsco/destiny-clan-warfare/node_modules/next/dist/server/api-utils.js:101:9)\n' +
  '    at async DevServer.handleApiRequest (/Users/benedfit/Projects/newhighsco/destiny-clan-warfare/node_modules/next/dist/server/next-server.js:770:9)\n' +
  '    at async Object.fn (/Users/benedfit/Projects/newhighsco/destiny-clan-warfare/node_modules/next/dist/server/next-server.js:661:37)',
name: 'Error'
},
error_description: 'Scope is always configured value. Do not specify scope parameter.',
body: '',
providerId: 'bungie',
message: 'invalid_scope'
}

tgallacher commented 2 years ago

hi 👋

Testing out the GoogleProvider on next-auth@4.0.0-beta.4 and hitting an error which prevents the user login flow to complete:

[next-auth][error][OAUTH_PARSE_PROFILE_ERROR]
https://next-auth.js.org/errors#oauth_parse_profile_error Cannot read property 'toString' of undefined {
  error: {
    message: "Cannot read property 'toString' of undefined",
    stack: "TypeError: Cannot read property 'toString' of undefined\n" +
      '    at getProfile (/Users/tomgallacher/Code/tgallacher/app-gsd-todos/node_modules/next-auth/core/lib/oauth/callback.js:168:39)\n' +
      '    at runMicrotasks (<anonymous>)\n' +
      '    at processTicksAndRejections (internal/process/task_queues.js:93:5)\n' +
      '    at async oAuthCallback (/Users/tomgallacher/Code/tgallacher/app-gsd-todos/node_modules/next-auth/core/lib/oauth/callback.js:131:27)\n' +
      '    at async Object.callback (/Users/tomgallacher/Code/tgallacher/app-gsd-todos/node_modules/next-auth/core/routes/callback.js:50:11)\n' +
      '    at async NextAuthHandler (/Users/tomgallacher/Code/tgallacher/app-gsd-todos/node_modules/next-auth/core/index.js:103:28)\n' +
      '    at async NextAuthNextHandler (/Users/tomgallacher/Code/tgallacher/app-gsd-todos/node_modules/next-auth/next/index.js:40:7)\n' +
      '    at async /Users/tomgallacher/Code/tgallacher/app-gsd-todos/node_modules/next-auth/next/index.js:80:32\n' +
      '    at async Object.apiResolver (/Users/tomgallacher/Code/tgallacher/app-gsd-todos/node_modules/next/dist/server/api-utils.js:101:9)\n' +
      '    at async DevServer.handleApiRequest (/Users/tomgallacher/Code/tgallacher/app-gsd-todos/node_modules/next/dist/server/next-server.js:770:9)',
    name: 'TypeError'
  },
  OAuthProfile: {
    // .. some data
  }

I believe this error didn't happen the first time I logged, but does on subsequent testing where the Google URL ends up being cached with a 302 redirect back to the NextJS app.

The error seems to be caused by this line: https://github.com/nextauthjs/next-auth/blob/v4.0.0-next.26/src/server/lib/oauth/callback.ts#L149.

The following workaround seems to work:

  GoogleProvider({
      clientSecret: process.env.GOOGLE_OAUTH_CLIENT_SECRET,
      clientId: process.env.GOOGLE_OUATH_CLIENT_ID,
      profile: (profile) => {
        return {
          id: profile.sub,
          ...profile,
        };
      },
    }),

Note: This error also happens in next-auth@4.0.0-beta.6.

balazsorban44 commented 2 years ago

Not sure how that would happen. We specifically don't spread the profile so we have a normalized/predictable default user profile for all the providers (especially important if someone wants to use a database).

You might have misconfigured Google. Make sure you follow the instructions at https://next-auth.js.org/providers/google

Here is a valid response from Google:

Your "workaround" would only work if Google returned an id, but as you can see above, it does not.

nextauthjs / next-auth

Manually Test Providers (v4) #2524

Description 📓

Notes