Unable to link azure-ad account to user due to email missing from profile.

[anguskeatinge]

I'm trying to get the azure-ad provider working.
Everything seems to work fine except for one thing - the email isn't included in the oauth profile. Instead we get an object like so:

 {
  sub: 'string', // this is the same as the account.providerAccountId
  name: 'My full name',
  family_name: 'my last name',
  given_name: 'my first name',
  picture: 'https://graph.microsoft.com/v1.0/me/photo/$value',
  user: null
}

This is linking the account, so I'm only doing this while I'm already logged in. Because of this, the sessionToken and therefore email and account are available in the request context, but not available in the callbacks.signIn context where I am handling the account linking / updating.

The best way I can think to work around this would be to fork the repo and pass this context through to the signin callback, but this isn't very nice.

Any ideas? Has anyone faced this before?

[balazsorban44]

Which version are you on? Could you paste in your code/link to a repository?

[balazsorban44]

The getUserByAccount method doesn't care about any of those parameters you passed in your PR, so I closed it.

[anguskeatinge]

Yep okay, but that PR had nothing to do with getUserByAccount. I mustn't have explained myself clearly.

Have a look at the PR again (I only put it there to help make my point), the purpose was to add session data to the signIn callback so you can make an informed decision about whether to block the creation of a new account or to approve the linking to an existing account.

This is particularly relevant for the providers who don't always provide an email (but it's also relevant for the providers who return unverified emails)

Let me outline the 2 relevant scenarios:

1. someone hits "sign in with Microsoft" while signed out and before linking that account to their user. I want to return false in the signIn callback so that NextAuth doesn't create a new user.
2. someone hits "link account to Microsoft" when they are already signed in. I want to return true in the signIn callback so that NextAuth goes ahead and links them.

The only way to do this is to have an isSignedIn boolean passed into the signIn callback. Even better to pass in the email they are signed in with that could allow you to do further verification checks.

[anguskeatinge]

@balazsorban44 does that make sense?

I'm currently using patch-package to fix this issue, I'd be happy to put a PR together - let me know.

[balazsorban44]

I currently don't have the capacity to think about this, I recommend using patch-package for the short-term, and feel free to ping me in a few weeks about it 🙏

I am putting together a release plan, roadmap after v4 right now.

[anguskeatinge]

Will do

[bartread]

I have a related problem. With Microsoft Entra ID (formerly known as AzureAD), for some users the only place you can get the email address is by decoding account.id_token using jwt.decode(), and then reading the email from either the email, preferred_username, or upn methods.

Of course, a Microsoft user isn't guaranteed to have an email address at all. However, for our customer base that's not an issue. They will always have an email address. The question is getting it.

So I look everywhere there can be an email: on the user (where it does sometimes live), on the profile, and in the token in the account. And I'll take it wherever I can find it.

My problem is this: despite I can retrieve the email address from id_token in the account, NextAuth ignores this. When it writes the user to the User table in PostgreSQL via the PrismaAdapter, it does not write the email address unless the email address is present in the user object.

This might well work for the majority of providers - and it certainly works fine for Google, which is the other SSO provider we support - but you cannot make this assumption with Microsoft. You need to look in multiple possible places for the email.

I cannot find an officially supported way of fixing this, and I do need to fix it, because it causes the rest of our organisation account creation process to play up.

The only thing I can think of, which seems a bit grim, is to hook into the linkAccount or signIn events, which are triggered after the signIn callback, and - critically - after the createUser event. This is good, because they give me access to the account object. From the account I can decode the id_token to get the email address. I can also get the providerAccountId (not always called this for all providers) via the profile or account objects, depending on provider and user account specifics, which is also on the message, from its id property.

I can then read the account row from the database, by looking up based on providerAccountId and, from this get the userId, which I can use to update the corresponding row in the User table with the user's email address.

This feels pretty ropey though, and it feels like something the AzureAD provider should handle.

Is there a better way that I can do this than what I'm suggesting above?

[bartread]

@balazsorban44 I'm going to try upgrading to latest to see if that fixes the problem as we are a little behind. Having looked through the releases I'm not that hopeful, but it has to be step 1 before I do anything more involved. My main worry - as yet unfounded - is that it might push us to do a mass upgrade of packages and, although I'd prefer for us to be more current, this is not a great time for that piece of work as we're trying to onboard a customer.

If a simple upgrade doesn't fix it, might you be open to a PR on @auth/core for the AzureAD provider or is this behaviour you'd prefer not to change?

[bartread]

Actually, don't worry @balazsorban44, this isn't your problem at all.

The whole reason this scenario occurs is because we want to allow customer organisations to enforce SSO, which is often a requirement of their compliance regime (e.g., CE+).

So SSO enforcement - which means users can only sign up or sign in using SSO - is a concept we've layered on top of NextAuth. This situation only arises because:

1. A client organisation has chosen to enforce SSO.

2. An administrative user from that organisation sends out an invitation to a new user.

3. User clicks on the link in the invite.

4. User signs up using their organisation's SSO provider - they never give us their email address directly, e.g., by signing up with credentials.

I don't get the vibe this is necessarily something NextAuth is intended to support out of the box?

As a result, perhaps the fix should sit with us, not within NextAuth.