You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: examples/wallet-auth/README.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,15 +9,15 @@ It contains two separate implementations:
9
9
10
10
**Auth Proxy Highlights**
11
11
12
-
-**Simplified setup:**No need to host or maintain your own authentication backend. The Auth Proxy is a managed, multi-tenant service that handles signing and forwarding authentication requests.
13
-
-**Built-in security:**Proxy keys are HPKE-encrypted inside Turnkey’s enclave and decrypted only in memory per request. Includes strict origin validation and CORS enforcement.
14
-
-**Centralized configuration:**Manage allowed origins, session lifetimes, email/SMS templates, and OAuth settings directly from the Turnkey Dashboard.
15
-
-**Faster development:**The frontend calls Auth Proxy endpoints directly — no backend endpoints needed for OTP, OAuth, or signup flows.
12
+
- No need to host or maintain your own authentication backend. The Auth Proxy is a managed, multi-tenant service that handles signing and forwarding authentication requests.
13
+
- Proxy keys are HPKE-encrypted inside Turnkey’s enclave and decrypted only in memory per request. Includes strict origin validation and CORS enforcement.
14
+
- Manage allowed origins, session lifetimes, email/SMS templates, and OAuth settings directly from the Turnkey Dashboard.
15
+
- The frontend calls Auth Proxy endpoints directly — no backend endpoints needed for OTP, OAuth, or signup flows.
16
16
17
17
**Custom Backend Highlights**
18
18
19
19
You could:
20
20
21
-
-**User data:**Store and retrieve user data associated with Turnkey sub-organizations.
22
-
-**Metrics and monitoring:**Add custom validations, rate limiting, and logging.
23
-
-**Co-signing capabilities:**Enable 2/2 signing patterns where your application is a co-signer.
21
+
- Store and retrieve user data associated with Turnkey sub-organizations.
22
+
- Add custom validations, rate limiting, and logging.
23
+
- Enable 2/2 signing patterns where your application is a co-signer.
Copy file name to clipboardExpand all lines: examples/wallet-auth/with-backend/README.md
+5-4Lines changed: 5 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,10 +13,10 @@ A high-level summary of the user experience and what appears on screen:
13
13
14
14
Once logged in, access a dashboard with two panels:
15
15
16
-
**Left:** sign messages and simple demo transactions for both Ethereum and Solana using the **selected** embedded **or** connected wallet. The signing and broadcasting behavior differs slightly depending on wallet type:
16
+
**Left:** sign messages and simple demo testnet transactions for both Ethereum (Sepolia testnet) and Solana (Devnet) using the **selected** embedded **or** connected wallet. The signing and broadcasting behavior differs slightly depending on wallet type:
17
17
18
18
-**Connected wallets**
19
-
- Ethereum: delegates to the wallet’s native `signAndSendTransaction` method. Does not require an rpcUrl (the wallet handles broadcasting).
19
+
- Ethereum: delegates to the wallet’s native `signAndSendTransaction` method. Does not require an rpcUrl (the external wallet provider handles broadcasting).
20
20
- Solana: signs locally with the connected wallet but requires an rpcUrl for broadcasting.
21
21
22
22
-**Embedded wallets**
@@ -27,15 +27,16 @@ Once logged in, access a dashboard with two panels:
27
27
Notes:
28
28
29
29
> In this demo, you can configure these URLs using `NEXT_PUBLIC_RPC_ETH` and `NEXT_PUBLIC_RPC_SOL`.
30
-
> Both Ethereum and Solana demo transactions are send-to-self transfers with zero value, purely for demonstration purposes.
30
+
> Both Ethereum and Solana demo testnet transactions are send-to-self transfers with zero value, purely for demonstration purposes.
31
31
32
32
**Right:** view all the sub-organization embedded and connected wallets.
33
33
34
34
## How it works
35
35
36
36
1. Build and sign a wallet login request **without submitting it to Turnkey** using [buildWalletLoginRequest()](https://github.com/tkhq/sdk/blob/fa54063a394bfef7ead9f64b72a093c5e696a401/packages/core/src/__clients__/core.ts#L797). This function performs the following:
37
37
38
-
- Initializes the wallet stamper, ensures a valid session public key (generating one if needed), and signs the login intent with the connected wallet.
38
+
- Generates a new key pair to serve as the session key and has the connected wallet sign a login intent containing the public key. This resulting stamped request can then be sent to Turnkey to register that key pair as a session key pair.
39
+
39
40
- For **Ethereum wallets**, the public key cannot be derived from the wallet address alone — it’s extracted from the signature included in the stamped login request.
40
41
- For **Solana wallets**, the wallet address itself is the public key, so it’s retrieved directly from the connected wallet.
Copy file name to clipboardExpand all lines: examples/wallet-auth/without-backend/README.md
+3-2Lines changed: 3 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,10 +13,10 @@ A high-level summary of the user experience and what appears on screen:
13
13
14
14
Once logged in, access a dashboard with two panels:
15
15
16
-
**Left:** sign messages and simple demo transactions for both Ethereum and Solana using the **selected** embedded **or** connected wallet. The signing and broadcasting behavior differs slightly depending on wallet type:
16
+
**Left:** sign messages and simple testnet demo transactions for both Ethereum (Sepolia testnet) and Solana (Devnet) using the **selected** embedded **or** connected wallet. The signing and broadcasting behavior differs slightly depending on wallet type:
17
17
18
18
-**Connected wallets**
19
-
- Ethereum: delegates to the wallet’s native `signAndSendTransaction` method. Does not require an rpcUrl (the wallet handles broadcasting).
19
+
- Ethereum: delegates to the wallet’s native `signAndSendTransaction` method. Does not require an rpcUrl (the external wallet provider handles broadcasting).
20
20
- Solana: signs locally with the connected wallet but requires an rpcUrl for broadcasting.
21
21
22
22
-**Embedded wallets**
@@ -76,6 +76,7 @@ Now open `.env.local` and add the missing environment variables:
0 commit comments