Why using custom auth for embedded wallets is dangerous

As web3 wallets become an essential feature in many apps, there’s a growing push toward convenient, embedded wallet solutions that enable in-app purchases, token management, and item transfers.

However, the way these wallets handle user authentication can be a hidden pitfall, introducing significant risks for developers and users alike. A trend among some wallet providers is to allow developers to authenticate users via custom authentication (auth) endpoints. 

While this approach may seem convenient, it fundamentally alters the security dynamics, creating custodial risks that developers often overlook. In this article, we’ll explore why custom auth for embedded wallets can be dangerous and why non-custodial solutions such as Sequence are more secure.

Understanding embedded wallet authentication

Most embedded wallets use a standard OAuth process to authenticate users via popular social providers, such as Google, Apple, or Microsoft. This authentication architecture involves three independent parties:

1. The client (the app or web interface used by the end-user)

2. The OAuth provider (e.g., Google, Apple), which is responsible for verifying user identity

3. The embedded wallet provider (e.g., Sequence), which manages the user’s wallet and independently validates the OAuth token

In this setup, the OAuth provider is a neutral third party. Since these OAuth providers are independent and credible entities, this architecture enables a non-custodial setup for the developer.

Importantly, the embedded wallet provider directly validates the auth token with the OAuth provider, ensuring that the user’s authentication is legitimate without giving any third party undue control over the wallet.

Diagram: Standard OAuth-Based Embedded Wallet Authentication

The problem with custom auth endpoints

Some embedded wallet providers allow developers to bypass this standard setup by offering custom auth endpoints. Here’s how it typically works:

1. Instead of connecting directly with a third-party auth provider, the developer sets up a custom endpoint that the wallet provider trusts.

2. This custom endpoint can receive, modify, and validate tokens—meaning the developer can pass any authentication token and pose as any user within the system.

Diagram: Custom Auth Endpoint Flow

This custom endpoint is controlled by the developer, which shifts the security responsibility significantly. Since the developer has full access to user assets and can effectively pose as any user, they become the custodian of the wallet by default. In other words, the developer has the technical capability to move user items, sign transactions, and access funds without user consent.

This setup creates a custodial architecture with substantial risks and responsibilities for developers and users alike:

1. Custodial risks: Since developers control the custom endpoint, they can validate any auth token passed, effectively holding custody of user funds. This goes against the principles of decentralization.

2. Security risks: If the custom auth is compromised, every user authenticated through it could be vulnerable to attacks, unauthorized item transfers, and data breaches. 

3. Regulatory and compliance burdens: Acting as a custodian introduces legal obligations that many developers are unprepared for. Handling user items implies compliance with financial regulations, such as those governing custodial services. Unaware of these obligations, developers could face legal repercussions.

How Sequence Embedded Wallet is different: A non-custodial approach

At Sequence, we’ve taken a different approach to ensure a non-custodial experience through Sequence Embedded Wallet. By integrating directly with third-party authentication providers (e.g., OAuth services) or through methods like email authentication, we eliminate the need for custom auth endpoints.

1. Direct integration with Auth providers: Sequence validates every auth session, for every transaction intent, directly with trusted, credible OAuth providers. When a user authenticates via Google, for instance, the user passes the authentication token to the Sequence SDK, which then independently validates it.

2. Smart account architecture: We leverage smart accounts to ensure that only user-initiated, approved actions can execute transactions. This setup creates an environment where each user’s smart wallet remains secure and under their sole control.

3. Non-custodial by design: By avoiding custom auth, Sequence Embedded Wallet ensures that user funds, items, and transactions are never accessible to anyone other than the user. Even as the embedded wallet provider, we have no access to move or control user items, reinforcing a genuinely non-custodial architecture.

We don’t take shortcuts. We achieved a smooth, web2-like UX with non-custodial wallets through years of research and multiple audits  - ensuring developers’ and their users’ security.

If you’d like to learn more about Sequence Embedded Wallet and why hundreds of developers leverage it to create seamless non-custodial gameplays, visit our website and reach out to our team!