Hi team,
I’m just learning about your product stack and I need your help with regards to my use-case.
I’m planning to build a web app for enterprise customers where they would login, get their Hedera wallet, add some funds, take their private key from the web app and put it in the API in their backend, and start sending transactions 24/7.
These customers shouldn’t have any prior knowledge about web3 nor should they even know that web3 (DLT) is used for their transactions. Having that in mind they should definitely have the option to recover their lost keys, or in case their employee who created the web3auth (with company email if that’s possible to set) isn’t working in the company anymore. All they need to know is that they’ve logged in, added some fiat to their account, and now they can send transactions (writing logs on-chain).
My questions are:
Is web3auth a perfect solution for that use case?
Will private key be always exposed on our web app or can we hide it and show it only on request, just like majority of web apps are showing API keys only when you press “Show” button?
If customer puts private key in the API from Hedera to send direct transactions, will there be any extra delay on every transaction from your side? My guess is no but better to check. I’m asking this question because you’ve said in your docs that it takes 1.2sec for user to login and sign transaction.
What auth options would you suggest to have in our case? We were thinking to have only email, but then we have that issue if user who created account is no longer working for the company.
What happens if user who created account looses the device where one part of the keys are stored? Can a user add new device to the list and get new set of keys or how does that work?
Will our customers have to login to your web app in any step of the user journey to do anything or they are doing everything in our app?
Can more users from the same company share the same wallet/account? I’m sure our customers would want to create more users so that their employees can access our app. Customer should have one web3 account/wallet, but should have the option for more than one employees to login and fetch these keys if needed.
Can we set the rule that part of the users keys is always stored on our premise to help them out recovering their keys in case they lose them?
Hi there! It’s great to see your interest in Web3Auth for your enterprise web app project. Let me address each of your questions to help you better understand how we can fit into your use case:
Web3Auth Suitability: Web3Auth is designed to simplify user onboarding by offering a secure authentication process without requiring users to understand the underlying web3 technologies. Your use case seems like a good fit, as it aligns with our goal to abstract the complexities of web3 from end-users.
Private Key Visibility: You can manage the visibility of private keys in your web app. Web3Auth allows you to control when keys are shown to users, often defaulting to being hidden unless explicitly requested by the user (e.g., pressing a “Show” button).
Transaction Delay: There should not be any inherent delay in transaction processing once the private key is in place in the Hedera API. The 1.2-second reference is typically specific to login and transaction signing time, not ongoing transactions.
Authentication Options: Email-based logins are a common choice. However, given your concern about users leaving the company, you might consider adding flexible login methods, such as OAuth with corporate accounts or employing multi-factor authentication for additional security.
Key Recovery: Web3Auth allows for key recovery if the user loses their device. Users can generally add a new device to their trusted device list, and with Web3Auth’s multi-factor authentication, you can set up mechanisms to help recover keys or reconstruct them using security measures.
User Journey: Your customers will primarily interact with your app, and they will not need to log into any separate Web3Auth web app. The authentication process is embedded within your application.
Shared Wallet/Account: Web3Auth can support enabling multiple users to access the same wallet/account, especially in an enterprise setup. However, you’ll need to implement the logic to manage permissions and access within your app, allowing multiple employees to access the same account.
Key Storage Rule: You can implement custom logic to manage part of the keys securely on your premises, serving as a recovery option while adhering to enterprise security standards and protocols.
For detailed implementation, I recommend checking the Web3Auth Developer Documentation and engaging in the Web3Auth Community Forum for specific examples and best practices. If further questions or a deeper technical dive is needed, feel free to reach out!
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
Hey @Redacted, here’s a breakdown addressing your questions:
Web3Auth Fit for Your Use Case
Yes, the Plug and Play SDKs are built for Web2-like onboarding. Users log in via social/email and instantly get a wallet. What you do with the private key post-login—store, show, restrict—is up to your app’s design. For recovery, as long as the user logs in with the same email and method (Google, Email, etc.), they’ll get the same wallet. With MFA set up, multiple fallback methods can be configured. For enterprise, using a central company email works well, even if the employee leaves.
Private Key Visibility
After login, the provider object lets you request the private key. You control when and how it’s shown—e.g., behind a “Show” button UI toggle. You can even disable private key access entirely from the Web3Auth dashboard.
Transaction Delays
None. Web3Auth hands off the private key. From that point, you’re handling everything—signing, sending, etc. There’s no interaction with Web3Auth after login unless you trigger it.
Auth Strategy
Use a company-controlled email or corporate OAuth. That way, key recovery or re-access doesn’t depend on a single individual’s identity.
Key Recovery Scenarios
If a user loses the device with the device share, they can recover using other configured factors—recovery password, passkeys, authenticator, or social backup logins. If all are lost, there’s no recovery—Web3Auth is non-custodial and doesn’t store keys.
User Journey
Your users never need to touch Web3Auth UI. You configure the dapp on our dashboard, embed the SDK in your app, and your users interact only with your frontend.
Multi-User Access to Same Wallet
Web3Auth is built around 1:1 identity to wallet (via verifierId). You can implement aggregate verifiers so users using different login methods (but same email) get the same address. But a single wallet shared across many logins isn’t natively supported—you’d need custom logic for that.
Storing Part of the Key On-Prem
You can request the private key on login and store it yourself—turning your dapp into a custodial one. That’s fine if your users are informed. For more control and recovery logic, you should explore our MPC Core Kit—it’s built for this level of enterprise flexibility.
Docs: