Access Web3Auth Wallet on Backend After Frontend Login

[arjav]

• Platform: Node JS

• Browser Console Screenshots: Here is the code for the frontend
  

  

• If the issue is related to Custom Authentication, please include the following information (optional):

  • Verifier Name: Daxi Staging
  • JWKS Endpoint: https://www.googleapis.com/service_accounts/v1/jwk/securetoken@system.gserviceaccount.com
  • Sample idToken (JWT): eyJhbGciOiJSUzI1NiIsImtpZCI6ImE0YTEwZGVjZTk4MzY2ZDZmNjNlMTY3Mjg2YWU5YjYxMWQyYmFhMjciLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJodHRwczovL3NlY3VyZXRva2VuLmdvb2dsZS5jb20vY2FzaG8tc3RhZ2luZyIsImF1ZCI6ImNhc2hvLXN0YWdpbmciLCJhdXRoX3RpbWUiOjE3NTAzMzgxMjIsInVzZXJfaWQiOiJhYzhVemlRdWpLZUV0alVnT2hoNUxjSWV1djEyIiwic3ViIjoiYWM4VXppUXVqS2VFdGpVZ09oaDVMY0lldXYxMiIsImlhdCI6MTc1MDMzODEyMiwiZXhwIjoxNzUwMzQxNzIyLCJwaG9uZV9udW1iZXIiOiIrOTE5OTk5OTk5OTk5IiwiZmlyZWJhc2UiOnsiaWRlbnRpdGllcyI6eyJwaG9uZSI6WyIrOTE5OTk5OTk5OTk5Il19LCJzaWduX2luX3Byb3ZpZGVyIjoicGhvbmUifX0.KvHZz5kuAz5M5jgZ2ikKGfpEWkYKyEus-aW7tr6dqmxsIDKU9_x0seuSuHqU_2NIXtSy9xXUg6IDYO84grUoovWPmZ7Gl23cRy8sO9o1bV-fH4tZ9k2c5QfhI0u27fPbtHtl9N4dQeOP2kqVWqatFC4iL9-fI7MmgYXTgPloLdJsUlCxj3ZmMOW6FeNExGrTSC88-r0ectIMye1yV4QnSh-qtlQL-HI39arg8XgvNX_zEP2hIoJaD0GtncGBeEnBhQBLPgEEiHn-vap8ZuP6kkMpW1kzt3YNtQbQixtfQl8HHpb7yq3EdoMQW8MSJqkbiXnBIU0ryFF_TIqfpT5JJg

Once we generate the wallet and log in on the frontend:

How do we access the wallet or sign transactions from the backend (Node.js), on behalf of the user?

We’d like to perform server-side operations (e.g., sending a transaction) without prompting the user again or accessing their private key in the frontend.

We’re looking for guidance on:

• Secure delegation or relaying mechanisms
• Best practices for backend transaction signing
• Whether Web3Auth supports backend wallet access for authenticated users

Secondly,
Upon successful authentication, we also receive an ID token issued by Web3Auth:

What is the intended use of this idToken?

• Can this token be used on the backend to retrieve or reconstruct the user’s private key?
• Or is it solely for authentication/authorization (i.e., identifying the user identity securely)?
• If it can’t be used to derive the private key, what is the correct flow for backend services to act on behalf of the user?

[w3abot]

Thanks for the detailed context and code! Here’s a summary of your questions and the relevant details for the support team:

---

Summary of Your Query

1. Accessing Web3Auth Wallet on Backend After Frontend Login

• Goal: You want to perform server-side (Node.js) operations—like signing transactions—on behalf of a user, after they’ve logged in via the frontend (using Web3Auth with a custom verifier for Telegram).
• Key Requirement: You want to do this without exposing the user’s private key to the frontend or prompting them again.
• Platform: Node.js backend, PnP Web SDK on frontend.
• Custom Auth Details:
  • Verifier Name: Daxi Staging
  • JWKS Endpoint: https://www.googleapis.com/service_accounts/v1/jwk/securetoken@system.gserviceaccount.com
  • Sample idToken: Provided above

2. About the Web3Auth idToken

• Questions:
  • What is the intended use of the idToken issued by Web3Auth?
  • Can it be used to retrieve/reconstruct the user’s private key on the backend?
  • If not, what is the correct flow for backend services to act on behalf of the user?

---

Key Points and Answers

A. Can the Backend Access the User’s Wallet/Private Key?

Short Answer:
No, Web3Auth does not support reconstructing or accessing the user’s private key on the backend using the idToken or any other means.
The private key is generated and managed client-side, and is never sent to the backend or Web3Auth servers. This is by design for user security.

Supporting Docs:

• Web3Auth FAQ: Can I get the private key on the backend?
• Security Model

What does the idToken do?

• The idToken is for authentication and authorization—it allows your backend to verify the identity of the user (e.g., via JWT verification using your JWKS endpoint).
• It cannot be used to reconstruct or access the private key.
• It is not a session token for wallet access.

B. What is the Correct Flow for Backend Transaction Signing?

If you need to sign transactions on behalf of the user:

• You must do it on the frontend where the private key exists (in the user’s session).
• If you want to perform actions on the backend, you can:
  1. Have the frontend sign the transaction (or message) and send the signed payload to your backend for broadcasting or further processing.
  2. Use a relayer pattern: The backend can prepare the transaction data, send it to the frontend for signing, and then the frontend returns the signed data for the backend to submit to the blockchain.

Why?

• This ensures the user’s private key is never exposed or transmitted, maintaining security.

Docs for Reference:

• Web3Auth: How to sign transactions
• Best practices for relayer patterns

C. Secure Delegation or Relaying Mechanisms

• You can implement a meta-transaction or relayer pattern, where the backend acts as a relayer, but the actual signing always happens on the client.
• If you need backend-initiated actions, consider using a service account or a separate backend wallet (not the user’s wallet).

---

Summary Table

Can backend access user’s private key?	Can backend sign as user?	What is idToken for?	Correct flow for backend actions
No	No	Authentication/authorization (identity)	Frontend signs → backend relays/broadcasts

---

Next Steps / Recommendations

• Authenticate users on the backend using the idToken (JWT).
• For signing, always involve the frontend where the private key is available.
• If you need backend-initiated actions, use a dedicated backend wallet.

---

References

• Web3Auth FAQ: Backend Private Key Access
• Web3Auth Security Model
• How to Sign Transactions with Web3Auth
• Telegram Mini App Example (Client + Server)

---

If you have a specific use case that requires backend signing, please share more about your requirements, and we can suggest alternative architectures!

Let me know if you need code snippets or more details on implementing the relayer pattern.

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.

Additionally, we would recommend you to join our biweekly Office Hours to get this resolved even faster. Web3Auth Developer Office Hours

[maharshi]

Hey @arjav
The idToken is solely for authentication purposes on the frontend, and post that other shares(device, social, etc) are used along with the primary login idtoken to reconstruct the private key on the client side.
Please consider using single factor auth JS SDK with the mode as “node” for now.