We automatically link user accounts (based on same email address) using a Rule that is a minor modification to the template link-users-by-email rule:
https://github.com/auth0/rules/blob/master/rules/link-users-by-email.md
We are running into an issue when linking occurs. Our mobile (native) clients use refresh tokens in order to renew access tokens. After linking occurs, the refresh token we received from /authenticate isn’t valid. Subsequently passing that refresh token to /token returns a 403 { “error”: “invalid_grant”, “error_description”: “The refresh_token was generated for a user who doesn’t exist anymore.” }
FYI: Our link accounts Rule never changes the id of an ‘original user’ and it sets context.primaryUser = originalUserId (per this fix. Sign in to GitHub · GitHub)
I cannot confirm this, but I suspect the refresh token is for the ‘new user’, which is effectively ‘discarded’ as the account is linked (again, in our rule the oldest (original) account always wins). The access token returned from /authenticate is valid and for the ‘original user’.
Is there anything additional we should do in our account-linking Rule in order for the refresh token to work with the ‘original’ user?
I was able to reproduce the situation and to my knowledge there was nothing additional that you would need to set in the rule besides the context.primaryUser which should signal that the original user is the one that should be maintained as the primary identity. The problem is also constrained to the refresh token as the issued access token does reflect that the original user identity is the primary identity resulting from the completed authentication step; this fact supports that the behavior with the refresh token is likely an issue. I will raise the issue internally and will update this post when I have additional information.
Update: The root cause has been identified and the issue is now planned to be addressed; when the situation is fixed I can follow-up with another update.
Thank you so much @jmangelo, we appreciate the response.
Hi @jmangelo - we have run into the exact same issue as @joe.tillotson on our production apps. Do you have any updates on when this critical issue will be resolved? Additionally - does the development team know when this bug was introduced into production - we would like to be able to be able to understand the extent of our customer impact. Thank you for your assistance in this matter.
@waiyong.low there are no updates in terms of relevant news, I know that the situation is being reviewed, but that’s it; I will add your report also as a note in the internal issue. With regards to when it was introduced I’ll inquire about this, but I would say the behavior might have been there from the start since the context.primaryUser was introduced.
@jmangelo Thank you for the update. In the interim, is there any work around that you can suggest? For example, is there a way to 1) trigger an authentication event via the passwordless “email” connection, and 2) request the access / refresh token, so that when a user actually logs in for the first time, they will not run into this issue?
The issue is specific to linking accounts during rules processing so if you’re able to avoid linking accounts in rules then you may be able to bypass the issue entirely. For example, link accounts through the management API, but after an event triggered from your own client application instead of rules.
Gotcha, understood. For us there are (likely) future scenarios where allowing users to link from within a client will be useful, but for this ‘bread-n-butter’ scenario (user logs in using a 2nd (or 3rd) connection mechanism using the same email address), then doing the account-link within a rule is vastly preferred vs. initiating it within each client.