You don't need to define the callbackUrl if you only want to return to the same page, it's the default behaviour already. It sounds strange though that it works for one provider but not the other.

I'm wondering if this section is relevant, have you seen it?: https://next-auth.js.org/providers/apple#testing

Aside from that, any good reason for using useSecureCookies: false? Hope it's not in production, because it is a security risk. I would also not expose the idToken to the client through the session callback like that. Curious what you are trying to achieve with it. 🤔

@balazsorban44 About useSecureCookies, I use it for testing only.
I've checked the logs in callbacks: redirect function.
The current url still be keep when we navigate from webpage to apple authorize page. But when we navigate back to webpage it auto reset to root url.

@balazsorban44 I think it related to this lines. Because I see that the callback cookies has reset to baseUrl when navigating from apple authorize page to my website.

I had similar issues with azureb2c, this might offer a temporary alternative for testing until issue is fixed 👇🏾

#1542 (comment)

I also have the same issue with apple login.

I have the same login flow with facebook , google , which run ok but only apple doesn't..

I was able to fix the issue in azureb2c by adjusting the response_mode value in the AuthorizationUrl from form_post to query

Examples :
authorizationUrl: https://${tenantName}.b2clogin.com/${tenantName}.onmicrosoft.com/${loginFlow}/oauth2/v2.0/authorize?response_type=code+id_token+token&response_mode=query,

Hope this helps

Thank you @innowhat for the workaround, worked fine with Apple. However setting the response_mode to query doesn't allow any scope to be used to retrieve user info, sadly (although at this time scopes are also broken for Apple login)

I'm experiencing this issue too.
@FernandVEYRIER @innowhat - How can I use your response_mode workaround? Would I need to fork the repo and then edit packages/next-auth/src/providers/apple.ts?

Hi @KristenWilde, I have never used apple as a provider so cant really tell if the work around applies there as well.
Anyways, you could try overriding your apple provider while using the 'query' response_mode, and if works then perhaps you could raise a PR for a fix.

Here is an example of how it could look like, hope this helps.

export default NextAuth({
  providers: [
    {
      id: 'apple',
      name: 'Apple',
      type: 'oauth',
      version: '2.0',
      wellKnown: 'https://appleid.apple.com/.well-known/openid-configuration',
      authorization: {
        // note we use 'query' instead of 'form_post' here
        params: { scope: 'name email', response_mode: 'query' },
      },
      checks: ['pkce'],
      idToken: true,
      profile(profile) {
           ...
        }
      },
      options: {
        clientId: '',
        clientSecret: '',

        /**
   * Apple requires the client secret to be a JWT. You can generate one using the following script:
   * https://bal.so/apple-gen-secret
   * 
   * Read more: [Creating the Client Secret
](https://developer.apple.com/documentation/sign_in_with_apple/generate_and_validate_tokens#3262048)
   */
      },
    },
  ],
  ...
})

Note: this only applies to next-auth4 or later

Hi @KristenWilde, I have never used apple as a provider so cant really tell if the work around applies there as well. Anyways, you could try overriding your apple provider while using the 'query' response_mode, and if works then perhaps you could raise a PR for a fix.

Here is an example of how it could look like, hope this helps.

export default NextAuth({
  providers: [
    {
      id: 'apple',
      name: 'Apple',
      type: 'oauth',
      version: '2.0',
      wellKnown: 'https://appleid.apple.com/.well-known/openid-configuration',
      authorization: {
        // note we use 'query' instead of 'form_post' here
        params: { scope: 'name email', response_mode: 'query' },
      },
      checks: ['pkce'],
      idToken: true,
      profile(profile) {
           ...
        }
      },
      options: {
        clientId: '',
        clientSecret: '',

        /**
   * Apple requires the client secret to be a JWT. You can generate one using the following script:
   * https://bal.so/apple-gen-secret
   * 
   * Read more: [Creating the Client Secret
](https://developer.apple.com/documentation/sign_in_with_apple/generate_and_validate_tokens#3262048)
   */
      },
    },
  ],
  ...
})

Note: this only applies to next-auth4 or later

From my experience the scope doesn't work when setting the response_mode to query., and Apple denies the login. Removing the scope parameter fixes the problem.

Thanks @FernandVEYRIER and @innowhat! I am using an older version of next-auth, but it was easy to change the response_mode and remove the scope in the Providers.Apple config.

Providers.Apple({
        clientId: process.env.APPLE_ID,
        clientSecret: { ... },
        authorizationUrl:
          'https://appleid.apple.com/auth/authorize?response_type=code&id_token&response_mode=query', 
})

This worked for signing in and redirecting, but unfortunately my app doesn't work without the user's name and email.

We got the Apple redirect working by changing the cookie config for the callbackUrl. sameSite: 'lax' was a problem so we added this to our config:

 cookies: {
  callbackUrl: {
      name: `__Secure-next-auth.callback-url`,
      options: {
        httpOnly: false,
        sameSite: 'none',
        path: '/',
        secure: true,
      },
    },

(still using next-auth version 3).

I tested locally. It seems using signIn like this solves the problem. In your Apple Login Button onClick

onClick={() => {
  signIn( 'apple', 
    { callbackUrl: "https://<your-redirect-url>" },
    { redirect_uri: "https://<your-redirect-url>" });
}}

Edit: But not works if you don't apply api/auth/callback/apple to end of your url, And with that, It does not working again.
Edit2: @senad87 's solution works perfect 👌 Thanks.

Still having this problem

Still facing the issue for apple provider

next : 12.1.6
next-auth : 4.18.8

Got this problem currently. Is the root cause becuase Apple send POST request to the AuthJS callback instead of GET?

}
----- END JWT callback -----
 POST /api/auth/callback/apple 302 in 1899ms
----- START JWT callback -----

I implemented oAuth for Apple on Rails and had to do a workaround for this case, but I don't remember off the top of my head.