I have several questions related to updating the clientId/secret for existing custom verifiers:
As per my understanding, the verifier id received from Facebook to be used by the Torus network to retrieve the key shares is “facebook app”-specific. Is that right?
If so, does it mean that if I update the clientId/secret to a different fb app, will the existing users start getting different private keys from the torus network?
Is updating the clientId for other custom verifiers that have a user-specific verifier id (e.g. Google) generally safe to do?
I just tried logging in through Facebook using Customauth and our own Facebook app (still testing, not deployed anywhere), and the verifierId I got was 7594639233913470. I obtained that by checking the query string of the node-details request, e.g. https://fnd.web3auth.io/node-details?network=mainnet&verifier=tkey-facebook&verifierId=<xxxx>)
Whereas when I logged in with the same Facebook account directly through https://app.tor.us, the verifier id I got when I checked the requests was 6136392733071468. Similarly, when I logged in through FB in https://kukai.app which is also integrated with Web3Auth (CustomAuth), the verifier Id I got there was 6457964507580954. Kukai’s code is open-source and their integration details can be checked here
This seems to suggest that the Facebook verifier id depends on the underlying Facebook app facilitating the Facebook login, or do you see any other explanation?
It appears that the Facebook will give a different sub when you change the app client and secret and that generates a new key. Facebook is based on sub and not email in this case.
It is thus sugessted not to change the facebook app linked to a verifier and the same applies for Google, Twitter, etc. as you will not be able to migrate the old users onto the new app since their login will be treated as a new user and hence new private keys will be generated.
Thanks, got it. So changing the clientId for a Facebook verifier is a breaking change. Perhaps it could be worth a warning in the web3auth developer interface.
Could you clarify why changing the client id for a Google verifier could cause issues though? As far as I checked and understand, the verifierId remains the same (user email in case of Google) regardless of the Google clientId, which leads me to believe that as long as the idToken from Google is valid against the currently configured clientId for the verifier, I should get the same key shares from the Torus network, or am I missing something? Similarly for Twitter, Discord etc. (except Facebook)
@rafael.korbas Yes, definitely, we will take your feedback on this.
We do not suggest changing details to the verifier in this way. However, you may test it out as this is a unique scenario we are seeing. In the case of Twitter, Discord , there is a unique ID generated for each users as well like Facebook. Do test and let us know if you come across issues.
The unique identifier for Google login is the sub field, which is a globally unique identifier for the Google Account. This identifier should be used as the identifier for the user as it is unique among all Google accounts.
