feat: make tokens available in profile callback

[balazsorban44]

What:

Adds a new parameter to the profile() callback in provider options.

Why:
Since there is a lot of inconsistencies in OAuth provider implementations, the profile callback often provider an inconsistent result in its first parameter. The profile callback is called asynchronously, so it is a good place to fetch more data, but usually, that request should be authenticated by the logged-in user. Without an access_token, it is in most cases probably impossible.

How:

Forward tokens to profile, so it will receive these params:

async profile(profile, tokens) {
  const email = await getEmailForUser(tokens.access_token)
  return {
    id: profile.sub,
    name: profile.nickname,
    email,
    image: profile.picture
  }
}

We will forward all the tokens we have for a provider. Depending on which provider we talk about, you will have an access_token, id_token, and refresh_token.

Checklist:

• Documentation
• Tests
• Ready to be merged
  

Discusses briefly: #1238 (comment)

Multiple of our built-in providers also return null for email and image because of this. With an access_token available, it might be possible to fetch that info for those as well.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/nextauthjs/next-auth-jemaoisjy/nextauthjs
✅ Preview: https://next-auth-git-feature-return-accesstoken-profile.nextauthjs.vercel.app

[jackmerrill]

Hoping this gets merged! I hope this also clears the path for #955. Too much work for something so simple.

[ndom91]

That was easy enough of a change! Haha

LGTM 👍

[iaincollins]

Sorry it's taken a few days to get round to this and thank you for tagging me! :-)

Instead of passing a string as the second argument, I wonder if it's worth passing the entire tokens object to future proof things?

IIRC, the tokens object may optionally contain a raw id_token which might also be helpful to be able to access in some cases (although I think of that as more useful for advanced usage, like someone creating a new provider).

I appreciate having type definitions here would be helpful and that the object format varies between providers makes it ambiguous what will be returned, but if we only return a specific key of access_token, I think we are going to run into cases where it won't work for some folks, and just passing the entire object seems like a helpful thing to do.

Maybe we could then log a FIXME / TODO / or an issue to create and test better defined types with a range of providers to document them and see what they actually return?

[balazsorban44]

Thanks for the feedback! I can very easily send all the tokens as the second param, no problem. In v4, I would actually prefer if all our user facing apis could take a single object (aka named parameters) in case if they have more than one param. Easier to create types also. For now I can send the tokens and we see what we come up with later.

[github-actions]

🎉 This PR is included in version 3.5.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 4.1.0-next.1 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 4.0.0-next.5 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀