Microsoft Windows Live account not providing email address for only one user in the system

Help
, ,
1

We are having trouble with just one of our many users. When this particular user logs in to our site using his Microsoft Windows Live account, Auth0 is not providing his email address. Our system requires the email address because it is the unique identifier for each user. Without the email address, our site rejects the login.

Auth0 logs show that the user logged in successfully but the log does not show the user’s email address. For all other users in our system, the log shows their email address. We know we have the right user because the log does show his IP Address (which is his personal home IP address).

Even in the list of logs, the “Successful Login” logs show the email address of all other users in the Description column but for this user it is blank.

![alt text][1]

In the Users page, Auth0 shows this user but it does not provide a name or email address for them. The name just shows as N/A and the email address does not show.

![alt text][2]

We have several users on our system, using either Google or Microsoft Windows Live accounts. All of them can authenticate successfully except for this one user. This user can use their Google account (it has a different email address) and it works successfully.

Our Auth0 settings require the Email Address for Microsoft Windows Live account users (and for our Google users).

![alt text][3]

We have eliminated the user’s browser, computer and IP. He tried several browsers with the same results. He can log in using his Google account on the same browser and it works. He shared his desktop with me via Skype and I successfully logged in using my own Microsoft Windows Live account on his browser. Auth0 did provide us with the email address when I logged in as myself.

He can also successfully log into our smoke test environment, which is a copy of our live system but it uses a different Auth0 account. That account is getting his email address.

![alt text][4]

He did not refuse to provide his email address when his Microsoft Windows Live account asked him whether our system could access some of his personal information (basic profile and email). In fact, his Microsoft Windows Live account settings clearly show that he IS allowing us to have his email address.

![alt text][5]

I watched as he removed permissions to our Website from his Microsoft Windows Live account. When he went back to our site, it prompted him again for his information (basic profile and email address). He accepted. Again, Auth0 shows that “someone” successfully logged in from his IP address but their display name and email address are blank.

I went into the user in the Auth0 management portal and removed him. He logged in again and we have the same result. Auth0 once again shows a user with no name and no email address.

We have eliminated everything we can think of before reaching out to support. It seems to be some combination of our production Auth0 account and this one user’s Microsoft Windows Live account.

Any help is greatly appreciated.

Thanks

2

That’s a really good and detailed problem report. As somewhat expected I was not able to reproduce this with a local test account and my own Microsoft Live account.

You mention that the user in question is processed correctly in an test Auth0 account you have, but on the production account it has the missing email problem. Are you using the same Windows Live configuration in both accounts (same client identifier and secret) or does the test account use a different configuration? If it uses a different one can you repeat the steps in the test account with the same Windows Live client configuration used in your production account?

The above should tell us if this is likely to just be related to the Windows Live application configuration (client identifier/secret) or if it may also be related to some difference between the Auth0 account configuration being used in the two accounts.

In addition to the above I would also recommend you to do the following:

  1. Request the problematic user to perform a login; you may need to do this in order to then have a valid access token given that any existing one may already have expired.
  2. Obtain the Windows Live access token that is generated as part of the login procedure.
  1. Call (HTTP GET) https://apis.live.net/v5.0/me?access_token={USER_ACCESS_TOKEN} endpoint and save the JSON results.

You can do the above steps both with the working configuration and non-working configuration so that you can compare the JSON profile that is being returned by Windows Live API in both cases. This may make evident what’s the problem, but if it doesn’t update the question with the JSON results for both scenarios (replace private/sensitive information with placeholder text).

3

Thanks, jmangelo

This was very helpful. We did a test on several accounts within our company using what you suggested, checking both the smoke test and the production Auth0 accounts. We found a few other accounts with the same problem and noticed a pattern.

“email_verified”: false

This showed up in all of the ones that failed. For the ones that succeeded, this was set to true.

We then dug a little further. My coworker was one of those impacted and he looked at his Microsoft Windows Live account settings. In his live.com profile, his Contact Information did not specify a Personal Email. He set his personal email to the same email he uses to log in and it worked.

![alt text][1]

We checked the same thing with another impacted coworker and found he didn’t have his personal email set up. He set it up and it worked. So the accounts that were verified, such as mine, must have also had the personal email address set up.

What is strange, however, is that another coworker who is impacted can log into our smoke test site but not the production environment. I haven’t checked to see whether his personal email is set up or not. If it’s not set up then it’s strange that he can log into the smoke test site.

Thanks again, jmangelo. This gives us a work-around and a lead to follow.