Login on a new device




Phrases obtained from email or those from app.openlogin.com to be able to log in there.
The web that I go to app.tea.xyz

Hmmm, could you please explain the unexpected behaviors mentioned above?

@TomTom Hi sir, I’m not looking to enable more MFA factors, I’m stuck on the issue of the MFA’s values being unable to verify the new device.

This means that the MFA doesn’t work correctly, I think this is a fatal bug…

hi @Halimao

Sorry about my confusion. This post is too long with different topics.

The backup phrase is always sent by email and you have to verify it as soon as you get it.
To activate it you must have it in your email and copy it to the text area. Otherwise, it will not let you.

@TomTom Hi sir, thanks for your reply.

I’m sorry, did you mean that the backup phrase will be sent every time I choose the email MFA verification? Something like the screenshot above?

I just got an email after I logged in to this community and chose the email MFA verification.

Unfortunately, when I try to log in to https://app.tea.xyz, the email verification is unable to be clicked, and no backup phrase is received in my email. (See the screenshot below)

The other MFA verification value I used to verify, all failed. This is a bug IMO.

This issue looks like the account I used to log in to this community differs from the one I used to log in to https://app.tea.xyz. Although both used the web3auth and the same Discord account to log in?

@TomTom Hi sir, could you please explain the issue mentioned above?

@TomTom @yashovardhan Hi sir, could you please explain the issue mentioned above?

Both https://aap.tea.xyz and https://web3auth.io/community use the same web3auth account, both logged in with the same discord account, but when verifying MFA, the devices of both are different. This doesn’t make sense.

Hi @Halimao,

In Web3Auth, each project is assigned a unique client ID. This means that if you were to configure Web3Auth into an app, each project you create via the Web3Auth dashboard would have its own distinct client ID.

Given this setup, it’s expected that the client ID for the community as a project and the client ID for your own app would be different. Consequently, the authentication systems would be distinct, leading to different accounts for each project. This is by design to ensure that each project’s authentication environment is isolated and secure.