Please correct my understanding how Single factor authentication works

[alekhinalexandr.94]

Could you explain how and where a user’s private key is generated in the case of single-factor registration?

Here’s my understanding of the process:

1. The user clicks the “Register with Google ID” button.
2. They are redirected to the Google page, where they grant permission for the Web3Auth application to access their data.
3. Web3Auth receives a JWT token from Google, signed by Google.
4. Web3Auth performs two actions:
   *If the user doesn’t already have an account for this specific application, it somehow stores shares of their private key in the Auth network.

• Web3Auth creates an object that is returned to the frontend, which includes information about the user (email, public key) and a JWT token.

5. Now, on the frontend/backend of the application, we can verify that the user has the right to access the application.

In this flow, the private key never explicitly appears, which raises the question of how the user accesses their key created by Web3Auth during registration. More importantly, how does this process work?

Here’s my deeper inquiry:

1. As a user, I only have access to my Google ID but want to sign a transaction with my Web3Auth wallet.
2. I need to authenticate with Web3Auth (via my Google account and granting Web3Auth access).
3. Web3Auth verifies that I am indeed the account owner and returns an object with a JWT token.
4. The frontend where I registered stores this JWT token in cookies or somewhere else.
5. When the user wants to sign a transaction with Web3Auth wallet, they send this JWT token to Web3Auth, which somehow uses MPC to request key generation from the Auth network.

What’s unclear to me is where the private key is generated: on the Web3Auth server or on the user’s frontend?

I may have completely misunderstood how this works—please correct me!

[w3abot]

Hi Alexander! Thank you for your detailed inquiry about single-factor authentication with Web3Auth. Your understanding is quite comprehensive, and I appreciate the way you’ve broken down the process. Let’s clarify a few points regarding how the private key works in this context.

1. Private Key Generation: In the case of single-factor authentication, the private key is generated via a multi-party computation (MPC) protocol, which occurs in the Web3Auth infrastructure. The key is not stored on the user’s device or the frontend of your application but is instead split into shares and distributed across multiple parties in a secure manner. This ensures that no single entity has access to the complete private key.

2. JWT Token Usage: After you authenticate using your Google ID and Web3Auth verifies your identity, the JWT token facilitates seamless access to your wallet. When you want to sign a transaction, the frontend can send the JWT token to Web3Auth’s servers. Web3Auth then uses this token to retrieve the necessary key shares through the MPC process to reconstruct the private key temporarily for signing the transaction.

3. User Access: So, while you only have access to your Google ID, and the private key never appears directly in your frontend or server, it is generated and securely managed by Web3Auth. The authentication process ensures that although users won’t see the private keys, they can still perform operations requiring those keys through the issuance of JWTs.

Your process seems to be quite aligned with how Web3Auth is designed to work. Each detail you listed fits well into the overall authentication and key management lifecycle.

If you have any further questions or need more clarification on specific parts, feel free to ask! I’m here to help!

Note: This response was generated by an AI bot and may require further verification. The Web3Auth support team has tracked this issue and will be responding as soon as possible.

[alekhinalexandr.94]

I would like to know what realy happen here:

async getPrivateKey() {
const privateKey = await web3auth.provider.request({
method: “eth_private_key”
});
}

[alekhinalexandr.94]

@w3abot Please help) We are trying integrate your product but need to figure out some details) Do you have TG to discuss?

[Ayush]

Hey @alekhinalexandr.94 sorry for the delays, your 4, and 5 point are not correct. The JWT token is never stored on frontend by the SDK, and used later to request key generation.

When you use connect method in the SFA SDK, it takes the idToken, JWT verification field, and verifier name. The Auth network will verify your idToken and check if the verification field is present or not in the idToken. The JWT validation happens through JWKS which you give during creating the custom verifier.

Once the JWT token is validated and verification field is present, the Auth network returns shares of the key to the frontend. On receiving these shares, the SDK uses Shamir Secret Sharing (SSS) to reconstruct the private key on the frontend.

Hence, when you can the eth_private_key it returns the secp256k1 key to you. You can read here: Single Factor Auth SDKs | Documentation | Web3Auth