Creating a new `User` in our own database

Help - Plug n Play
1

We have successfully implemented the web3Auth modal and we’re currently receiving the JWT issued by web3Auth without problem.

Just like the sample in the docs, we are getting a JWT payload (decoded) that looks like this:

{
  "iat": 1655835494,
  "aud": "BCtbnOamqh0cJFEUYA0NB5YkvBECZ3HLZsKfvSRBvew2EiiKW3UxpyQASSR0artjQkiUOCHeZ_ZeygXpYpxZjOs",
  "iss": "https://api.openlogin.com/",
  "email": "xyz@xyz.com",
  "name": "John Doe",
  "profileImage": "https://lh3.googleusercontent.com/a/AATXAJx3lnGmHiM4K97uLo9Rb0AxOceH-dQCBSRqGbck=s96-c",
  "verifier": "torus",
  "verifierId": "xyz@xyz.com",
  "aggregateVerifier": "tkey-google-lrc",
  "exp": 1655921894,
  "wallets": [
    {
      "public_key": "035143318b83eb5d31611f8c03582ab1200494f66f5e11a67c34f5581f48c1b70b",
      "type": "web3auth_key",
      "curve": "secp256k1"
    }
  ]
}

Now that we have this JWT token and some user data, I want to create a new User in my own database to extend even more information for a user. That being said, we need a reliable identifier we can use from this token to create that user in our database. So our goal then becomes: every time someone logs in, we check that identifier from the JWT issued by web3Auth against our User database and if it doesn’t exist, create one.

Email would be ideal but obviously it’s an optional field and some social logins probably wont have it.

Is the public_key in wallet going to stay consistent every login? Maybe we can use that?
or maybe the verifierId?

Any help would be greatly appreciated. We’re currently blocked!

2

@antonio Thanks for your question.

Your request has been forwarded to our team and we will get back to you with further updates once more information becomes available.

3

Just adding some of our additional findings so far.

We are considering using the verifierId along with either the verifier or aggregateVerifier to map to a User in our db. However, we have noticed that verifier seems to always default to torus and on the docs aggregateVerifier is said to be optional unless it is a single id verifier.

We aren’t too sure what single id verifier means and still are stuck as to which properties we can use reliably to map to a user.

4

Any updates here? @vjgee

5

@antonio I’m following up with our team for an update and will get back once more information becomes available.

6

Hey @antonio

In my opinion public key is the most consistent parameter here. The public key is the actual identity of the wallet of the user you’re creating. verifierId however, is from the social network, so it can differ or even be the same across different private keys.

7

Thank you. Do you know under what circumstance does the public key change? Or can we safely assume this won’t be changed.

8

if the public_key were to change all applications of this technology would break. so it’s safe to assume it won’t change

1 Like
9

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