Turnkey’s embedded wallet infrastructure now powers well over 50 million embedded wallets, giving us a clear view into how important the authentication layer is for teams building with this technology.
Authentication is both the front door of your application and the mechanism that unlocks signing, making it a design decision about both custody and user experience.
This guide breaks down how embedded wallet authentication works and what teams need to understand before designing the login flow.
What are embedded wallets?
An embedded wallet is a wallet built directly into an application. Instead of asking users to install a browser extension and write down a seed phrase, the app creates and manages the wallet behind a familiar login.
Embedded wallets sit alongside two older patterns. Compared to externally owned wallets and smart contract wallets, an embedded wallet keeps the self-custody of a traditional wallet but removes the seed phrase from the user's path entirely.
The tradeoff embedded wallets remove: Self-custody without seed phrases
For most of crypto's history, users had to choose between self-custody and good UX. Self-custody meant a browser extension and a seed phrase, while a smooth, familiar signup usually meant handing your keys to a custodian. Each path asked the user to give up something that mattered.
Embedded wallets remove the usual either-or between good UX and self-custody. A person signs in the way they would with any consumer app, and creates a wallet that only they can control.
A traditional seed-phrase wallet keeps the key on the user's own device, encrypted behind a password and derived from a seed phrase the user backs up and alone protects.
In that model the seed phrase is both the credential and the key, the one secret that proves you are the owner of your funds and are allowed to sign transactions. There is nothing to log in to and nothing separate to configure, because whoever holds the phrase holds the wallet.
An embedded wallet pulls those two roles apart. The key is handled behind the scenes, and the user holds a separate authentication credential whose only job is to authorize the key's use. Because the credential and the key are now different things, the credential becomes a layer you can shape: choose what it is, require more than one, rotate it, or add recovery.
Why authentication is at the heart of self-custodial embedded wallets
To understand why authentication matters so much for embedded wallets, start with the structure underneath it. Each end user has their own isolated wallet environment, and the application sits above those users as the product layer.
That structure creates an important separation. The application can read a user’s wallet data and help coordinate the experience, but it cannot simply write into the user’s wallet environment or sign on the user’s behalf. The backend can see that a wallet exists, prepare actions for the user, and display information in the app, but signing authority stays with the user.
Each user’s wallets and credentials are isolated from every other user and from the platform itself. The app cannot control the assets.
Every login method registers a credential inside the user’s own wallet environment. When a user logs in, they are proving control of something tied to that environment, whether that is a passkey, an email credential, or a social login.
Under the hood, familiar login methods resolve into cryptographic authorization, which is how something like an email login or social login can ultimately approve a signature without exposing a private key to the user or the application.
Authentication then becomes the bridge between a familiar login experience and wallet signing. The user experiences a standard sign-in flow. The wallet infrastructure sees proof that the right credential is present. Only then can a signing request be authorized.
Case study
See how Moonshot gave 1.5M users self-custody with passkey login
Building its embedded wallet infrastructure with Turnkey, Moonshot integrated passkey and email authentication with enclave-backed key storage. Users get full self-custody through biometric login instead of seed phrases.
Read the case study →How social login works without handing over your keys
A fair question follows from this. If a user signs in with a social login, does Google or another provider end up controlling the wallet, and could anyone who gets into that Google account move the funds?
Let’s give an example from Turnkey’s own infrastructure on how embedded wallets with social logins can work.
When a user logs in, Google issues an OIDC token. That token is a signed statement that says, “this is user X,” proving that user’s identity. Google never sees, holds, or creates the wallet’s private key. The wallet key is generated inside a secure enclave and never leaves it.
The social provider’s role is only to confirm who the user is.
Turnkey also binds that login to the user’s device. Before the login starts, the app creates a fresh keypair on the user’s device and includes a hash of the public key in the login request.
The enclave only accepts the login if the token matches that device keypair.
That means an intercepted token is not enough on its own. The attacker would also need the session key that stays on the user’s device.
Note that if a social login is the only credential on a wallet, then access to the wallet is only as strong as access to that social account, and someone who fully takes over a user's Google account could run a fresh login and reach the wallet.
That is why social login is best treated as one option. For optimal security, pair it with a passkey so signing also needs a credential that lives on the user's device, lean on the provider's own two-factor protections, and use policies to limit what a newly authenticated session can do.
A passkey can be unlocked with Face ID, Touch ID, a device PIN, or a hardware security key, but the passkey itself is a cryptographic credential that is connected to a specific app or domain. That means a look-alike phishing site cannot use the passkey to log in, and there is no code or reusable secret for an attacker to intercept and replay.
Passkeys are the strongest credential to place in front of actions that move funds. Social and email logins can make onboarding feel familiar, but passkeys protect signing and the movement of digital assets the best.
Policies also add another layer of protection if a login is compromised, limiing what a new session is allowed to do and letting teams restrict transfers by amount, asset, destination address, contract, and chains.
By using all of these protections, teams can give users a familiar login experience while keeping the actions that move digital assets more tightly controlled.
Turnkey security: The environment that keeps assets safe
Authentication only protects assets if the place where it resolves is itself secure. With Turnkey, that place is a secure enclave, a Trusted Execution Environment built on AWS Nitro.
The enclaves have no persistent storage, no interactive access, and no external networking, so a login credential unlocks signing only within that protected environment and nowhere else.
Keys are generated and used only inside it, never exposed to Turnkey, to your team, or to your software. The user authorizes every signature with their own credential, and because the model is non-custodial, users can always export their keys and leave, which means they are never locked into your app to access their own assets.
Turnkey authentication
Turnkey supports a range of login methods, and any of them can be the upfront login or an account the user links later. They all resolve to one user identity, so a person who signs up with email and later adds a passkey is still the same user. You can see the full list and setup in Turnkey's authentication documentation.
- Passkeys and biometrics. Passwordless login built on WebAuthn, using Face ID, Touch ID, or a hardware key.
- Email and SMS one-time codes. A passwordless code sent to a verified email address or phone number.
- Social and OAuth logins. Sign-in through providers like Google and Apple, plus others.
- External wallet login. Sign-In With Ethereum and Sign-In With Solana, for users who already have MetaMask or Phantom.
The point is flexibility. You can meet mainstream users with email or social login and still let crypto-native users connect an existing wallet, all inside the same app.
Who runs the login: managed service or your own backend
The one real decision in implementation is how much of the auth layer you want to own.
Turnkey offers a managed service called the Auth Proxy that runs one-time-code, OAuth, and signup flows for you, so you can ship a working login with no backend. This suits frontend-first apps that want to move quickly.
If you would rather own the flow, or you already run an identity system like Auth0, Cognito, or enterprise single sign-on, you do not have to replace it. You can keep your existing authentication and use Turnkey only for keys and signing.
The tradeoff is straightforward: the managed path is simpler to ship, while running your own gives you more control and lets you keep auth centralized where it already lives.
Getting started with Turnkey auth and embedded wallets
Embedded wallet authentication sits at the center of the user experience because it decides how users access their wallets and how signing gets authorized. The right auth model gives users a familiar login experience while keeping signing authority in their control.
Turnkey gives teams flexibility in how they build that experience. You can use passkeys and biometrics for strong device-bound authentication, email or SMS codes for familiar onboarding, social logins like Google or Apple for mainstream users, or external wallet login for crypto-native users. These methods can also be combined, so a user can start with email and later add a passkey for signing.
Teams also have a choice in how much of the auth flow they want to own. Turnkey’s Auth Proxy can run one-time-code, OAuth, and signup flows for teams that want to ship quickly without maintaining a backend auth layer. Teams with an existing identity system can keep it and use Turnkey for wallet creation, credential authorization, and signing.
For more information, see our docs on how to easily integrate embedded wallets and familiar authentication flows into your application.
Related articles
.png)
8 reasons the AI governance toolstack is being built onchain
Learn how Web3 infrastructure helps developers govern AI agents with identity, policy, and security controls before they transact.
Why the AI transformation in finance needs governance at the signing layer
As agents work longer and take on more autonomy, goal adherence has more room to drift. In agentic finance, that drift can put assets at risk.
