Example of getting email for Linkedin provider account during sign in and populating users record

[TimNZ]

Since Linkedin doesn't expose the email address of an account in the profile request,
you must use a separate call to grab it.

I wanted to deeply understand the architecture and sequence flow of next-auth operations, to find ways
to hack wanted changes/enhancements without having to fork.

This is an example of populating users.email during sign in, so it is populated into the users record in the db.
The signIn callback is called before the users record is created for a new user.

Note that 'r_emailaddress' has been added to the oauth requested scope:

You can't do the fetch in the profile() handler of the Provider options as you are not provided the accessToken.

Note: also using a custom Email provider which simply queues the email to be processed by a separate worker instead of trying to send it immediately.
Queueing the email e.g. async, means faster return time to request, and it doesn't break the signin flow if there's an issue generating the email e.g. the upstream mail server is dead.

import NextAuth from "next-auth"
import Providers from "next-auth/providers"
import AppStackEmailProvider from '../../../lib/next-auth/appstack-email-signin-provider'
const options = {
  site: process.env.NEXTAUTH_URL,
	callbacks: {
		signIn: async (user,account,profile) => {
			if (!user.email)
			{
				console.log('Retrieving and adding email to users record')
				const response = await fetch('https://api.linkedin.com/v2/emailAddress?q=members&projection=(elements*(handle~))', {method:'GET', 
					headers: {'Authorization': 'Bearer ' + account.accessToken}})
				const json = await response.json()
				user.email = json.elements[0]['handle~'].emailAddress
			}
		}
	},
	pages: {
		newUser: '/user/onboard'
	},
  providers: [
    AppStackEmailProvider({
      server: process.env.THISAPP_EMAIL_SERVER,
      from: process.env.THISAPP_EMAIL_FROM
    }),
    Providers.LinkedIn({
      clientId: process.env.THISAPP_LINKEDIN_CLIENT_ID,
      clientSecret: process.env.THISAPP_LINKEDIN_CLIENT_SECRET,
			scope: 'r_liteprofile r_emailaddress',
			profile: async (profile) => {
					return {
						id: profile.id,
						name: profile.localizedFirstName + ' ' + profile.localizedLastName,
						email: null,
						image: null
					}
				}			
    }),
  ],
  database: {
    type: "postgres",
    host: "127.0.0.1",
    username: "nextauth",
    password: "nextauth",
    database: "next-auth",
  },
}

export default (req, res) => NextAuth(req, res, options)

[iaincollins]

Thank you for this!

I've been thinking about adding some sort of option to Providers to support this (e.g. passing the Access Token to the callback or add the option to specify an additional profile details URL) as I think I ran into one other site where this can happen - although it's unusual.

We might also want to consider passing the contents ID Token to the getProfile() function.

cc @balazsorban44 in case that last comment is interesting / seems worth considering.

[balazsorban44]

I think it would make sense to expose the access token in the profile callback on the provider.

#817 would also benefit from it, I think.

Although lately I have been thinking that since we have the provider ids, we could do things like this internally, and keep the api simple.

See #1022

At the end, we would like to give the user a zero-config experience.

Less exposure can also mean more security.