Inconsistent email address between "token" and "user"

Hi Asana friends!

We found something strange in the authentication process, we think that during the authentication, we get the wrong email address for users in some cases.

I think that happen if a user changes its email address in Asana.

When we request the first token, during authentication, or when we refresh it, using that url:
POST https://app.asana.com/-/oauth_token

In the response, we receive the email address of the user.
In our app (bridge24.com), we keep it and update the local customer information.

But, some users contacted us, asking why we use an old email address they they no longer use in Asana.

After some analysis, we found that:
When we query
GET /users/me/
for these users, the email received is not the same. It’s the good one.

It looks like the oauth_token endpoint is not returning the actual email address, but the original address that was used when the user creates its Asana account initially.

Have you ever experienced it?

1 Like

@sasha_f @John_Vu ?

1 Like

In case you are interested in what Asana support told me when I contacted support about it.

It’s normal, because we can add more than one email in our account. (???)
Ok, and??

Nothing about, why do I get a different email between “token” and “user”.

So, we will keep the fix we added, after getting the token, we do not use that email as reference, but we do another GET to /user/me, and we use that email instead.

2 Likes

Hi @Frederic_Malenfant,

Apologies for the late reply. Can you give me more details on the scenario to help my understanding.

Here’s what I understand from your question.

Scenario:

  1. USER_A changes their email in Asana from user_a@example.com to user_a_new@example.com
  2. USER_A auth with bridge24.com app
  3. bridge24.com app calls POST https://app.asana.com/-/oauth_token and in the response Asana returns it looks like:
{
  "access_token": "f6ds7fdsa69ags7ag9sd5a",
  "expires_in": 3600,
  "token_type": "bearer",
  "data": {
    "id": 4673218951,
    "gid": "4673218951",
    "name": "Greg Sanchez",
    "email": "user_a@example.com"
  },
  "refresh_token": "hjkl325hjkl4325hj4kl32fjds"
}
  1. The expected value is:
{
  "access_token": "f6ds7fdsa69ags7ag9sd5a",
  "expires_in": 3600,
  "token_type": "bearer",
  "data": {
    "id": 4673218951,
    "gid": "4673218951",
    "name": "Greg Sanchez",
    "email": "user_a_new@example.com"
  },
  "refresh_token": "hjkl325hjkl4325hj4kl32fjds"
}

Is that the right understanding? If so, how long ago do you think the email change was from the OAuth step? My guess is that the time between the user updating their email in Asana to performing OAuth is not enough time for our writes to propagate and hence why we return the old email address. If the old email is still being shown in the OAuth response even after a few hours or days this might be a bug.

For now, it does seem like you have a workaround by using our Get a user (GET /users/{user_gid}) endpoint

Hi @John_Vu,

You are right, we think that we should receive the same email when we call “…/oauth_token” than when we call /users/me.

And, the good one is from /users/me.

I don’t know when it started, we recently changed our authentication method in B24, to only use asana oauth, instead of having an independent username/pwd for bridge24.
From that change, we decided to use asana email to update the contact info of our user.

That’s why some users contacted us about issues when we try to link their b24 account with asana account.

For them, they told us that the wrong email we use was changed several months or years ago in Asana!
So, I don’t think it’s a propagation issue :slight_smile: !!

I don’t know the exact reason why we get that situation, and steps to reproduce. I don’t know if it always occurs if someone change its email.

But, for now, we’re ok with the workaround we added.

Hi @Frederic_Malenfant,

Thank you for confirming. I’ll bring this up to our API team’s attention. I can’t guarantee that there will be an immediate fix if this was determined to be a bug, but I am glad that you were able to find a workaround with /users/me.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.