OAuth is now live on Turnkey!

Turnkey enables dramatically better crypto UX by allowing innovative teams like Infinex, Bullpen, Utopia, Alchemy, and Thunder Terminal to create secure non-custodial wallets for their users.

Previously, end users could authenticate with biometric passkeys, API keys, and email.  With OAuth, Turnkey customers and their users can now sign in with popular providers such as Google, Apple, and Facebook and approve transactions directly in-app — providing a seamless way to use web2 identity providers to authenticate into non-custodial wallets.

With this launch, Turnkey is taking one more step towards making wallets truly invisible. Your users don’t need to know they’re using crypto, even if they’re signing transactions onchain.

How OAuth works

We’ve added OAuth to the set of trusted authenticators that developers can add to sub-organizations, on top of API keys, email, and passkeys. As a result, your end user can just log in with Oauth, and take actions directly onchain from within your app.

You can check out an example of OAuth in our demo wallet, or check out our docs for how to configure OAuth for your own organization.

For a more detailed overview of how OAuth works and the challenges in building it securely, read on below, or take a technical deep dive in our first engineering blog post, coming tomorrow!

OAuth under the hood

Turnkey’s OAuth feature is built on OIDC (OpenID Connect). OIDC extends OAuth 2.0, which focuses on resource sharing, by providing user authentication through the following process: Users are redirected to their provider for login, then returned to the original website with a JWT containing authentication information.

We’ve taken a security-conscious approach to OAuth that utilizes TEEs, so that we can verify OIDC (OAuth) tokens in a fraud-proof way. Building on our existing TEE-based verifiable wallet infrastructure stack, we built a new secure enclave application to fetch content over TLS—known as our "TLS fetcher".

So, how does the TLS fetcher work? We’ve developed a way for enclaves to establish TLS connections, make requests, and cryptographically sign responses. Enclaves can contact remote hosts via a TCP (layer 4) proxy running outside of the trusted boundary. The secure enclave code asks the proxy to establish TCP-level connections, but remains in control of the TLS session (layer 7). The TLS session keys live in the secure enclave, on the target host, and nowhere else.

For a more technical perspective on TLS sessions within TEEs and the novel use cases it unlocks, read our Founding Engineer’s blog post with a deep dive on how we built the TLS fetcher enclave.

Stay tuned, or subscribe to our engineering blog ahead of time to get it when it drops.