במקום להכריח משתמשים לשמור ביטוי גיבוי (seed phrase) או להתקין את MetaMask, אתם נותנים להם התחברות דרך Google, Apple או אימייל. זה לא רק נוחות—זו המרה. קהל היעד הפוטנציאלי של ה-dApp שלכם רחב פי עשרה כשמסירים את החסם של התקנת תוסף. אנו משתמשים ב-Web3Auth כדי לפתור זאת ללא פשרות אבטחה. לפי ההערכות שלנו, Web3Auth מגדיל את קצב ההמרה בתהליך ההצטרפות פי 3–5 בהשוואה להזנה ידנית של ביטוי גיבוי.
מתחת למכסה המנוע, מדובר בקריפטוגרפיה מבוססת סף (MPC/TSS). בעת הרישום, נוצר צמד מפתחות, והמפתח הפרטי מחולק לשלושה חלקים: אחד מאוחסן בצמתי Web3Auth (tKey), אחד מקומית בדפדפן (deviceShare), ואחד כגיבוי אופציונלי (למשל, סיסמה). חתימה על עסקה דורשת שניים מתוך שלושת החלקים. Web3Auth לעולם לא מחזיק במפתח המלא. גם אם תוקף יפרוץ לתשתית שלהם, הוא לא יוכל לגשת לכספי המשתמשים.
כיצד קריפטוגרפיה מבוססת סף מגנה על משתמשים?
בניגוד לביטוי גיבוי המאוחסן במקום אחד ומועד לגניבה, MPC מחלקת את האמון. כל חלק מבודד, והסף (2 מתוך 3) מבטיח שפריצה לצומת אחד לא מעניקה גישה למפתח. זהו תקן אבטחה המשמש במערכות בנקאיות. כפי שצוין בתיעוד של Web3Auth, קריפטוגרפיה מבוססת סף מבטלת את נקודת הכשל היחידה.
כיצד פועל שחזור גישה?
המשתמש איבד את המכשיר? אין בעיה. הוא מתחבר שוב דרך אותו ספק OAuth, והמערכת משחזרת את חלק הגיבוי (אם הוגדר) או יוצרת deviceShare חדש עם אישור דרך גורם שני (סיסמת גיבוי). זהו שילוב של אחסון עצמי וארנק מנוהל: אתם שומרים על שליטה במפתחות, אך המשתמש לא צריך לזכור דבר.
למה לבחור ב-Web3Auth עבור ה-dApp שלכם?
Web3Auth מחזיר ספק סטנדרטי מסוג EIP-1193, כלומר הקוד הקיים שלכם שמשתמש ב-ethers.js, viem או wagmi עובד ללא שינויים. אתם פשוט מחליפים את import { Web3Auth } from '@web3auth/modal' import { CHAIN_NAMESPACES } from '@web3auth/base' const web3auth = new Web3Auth({ clientId: 'YOUR_CLIENT_ID', chainConfig: { chainNamespace: CHAIN_NAMESPACES.EIP155, chainId: '0x1', rpcTarget: 'https://rpc.ankr.com/eth' } }) await web3auth.initModal() // Вход — модал с Google/Twitter/Email/Apple const provider = await web3auth.connect() // Далее используем как обычный EIP-1193 provider const ethersProvider = new ethers.BrowserProvider(provider) const signer = await ethersProvider.getSigner() בספק מ-Web3Auth. כל המחסנית (signTypedData, שליחת ETH, אינטראקציה עם חוזים) נשארת זהה. אין נעילה לספק מסוים: אתם יכולים לעבור להפשטת מפתחות אחרת בכל עת.
השוואה בין Modal SDK ל-NoModal SDK
| קריטריון | Modal SDK | NoModal SDK |
|---|---|---|
| זמן אינטגרציה | 1-2 ימים | 1-2 שבועות |
| התאמת ממשק משתמש | מוגבל (מיתוג) | מלא (כל ממשק) |
| גמישות ספקים | כפתורים מוגדרים מראש | כל מתאמי OAuth לבחירתכם |
| מתאים ל | MVPs, אבות טיפוס | dApps בייצור עם חוויית משתמש ייחודית |
תהליך האינטגרציה
1. ניתוח
אנו מגדירים את קהל היעד, רשימת ספקי OAuth, דרישות white-label וצרכי התאמת ממשק המשתמש. אנו בוחרים את גרסת ה-SDK: Modal (ממשק מוכן) או NoModal (לוגיקה בלבד).
2. עיצוב
אנו מעצבים את תהליך האימות: רישום, התחברות, שחזור, ביטול סשן. אנו קובעים מנגנוני גיבוי (סיסמה, גיבוי חברתי). אנו משתלבים עם מערכת ההרשאות בקצה האחורי שלכם (JWT tokens, סשנים).
3. יישום
אנו מגדירים את לוח הבקרה של Web3Auth ומקבלים clientId. אנו מחברים את ה-SDK ומיישמים קריאות התחברות/התנתקות. הקוד לדוגמה למטה מציג אינטגרציה בסיסית של מודאל:
import { Web3Auth } from '@web3auth/modal'
import { CHAIN_NAMESPACES } from '@web3auth/base'
const web3auth = new Web3Auth({
clientId: 'YOUR_CLIENT_ID',
chainConfig: {
chainNamespace: CHAIN_NAMESPACES.EIP155,
chainId: '0x1',
rpcTarget: 'https://rpc.ankr.com/eth'
}
})
await web3auth.initModal()
// Вход — модал с Google/Twitter/Email/Apple
const provider = await web3auth.connect()
// Далее используем как обычный EIP-1193 provider
const ethersProvider = new ethers.BrowserProvider(provider)
const signer = await ethersProvider.getSigner()
4. White-label והתאמה אישית
לייצור, בדרך כלל תרצו מיתוג משלכם. אנו משתמשים ב-NoModal SDK:
import { Web3AuthNoModal } from '@web3auth/no-modal'
import { OpenloginAdapter } from '@web3auth/openlogin-adapter'
const web3auth = new Web3AuthNoModal({
clientId,
chainConfig
})
const openloginAdapter = new OpenloginAdapter({
adapterSettings: {
uxMode: 'redirect',
whiteLabel: {
appName: 'My App',
logoLight: 'https://example.com/logo.png',
defaultLanguage: 'ru'
}
}
})
web3auth.configureAdapter(openloginAdapter)
await web3auth.init()
// Вызов конкретного провайдера
await web3auth.connectTo('openlogin', {
loginProvider: 'google'
}) 5. בדיקות
אנו בודקים את כל התרחישים: התחברות ראשונה, חוזרת, אובדן מכשיר, ביטול גישה. אנו משתמשים ברשתות בדיקה (Goerli, Sepolia). אנו בודקים את זמן החתימה על עסקאות — MPC מוסיף כ-100-300 אלפיות שנייה, שאינו מורגש למשתמש.
6. פריסה ל-Mainnet
אנו משנים את ה-RPC, מעדכנים את ה-clientId לייצור ומפעילים מנגנוני גיבוי. אנו מגדירים ניטור דרך Tenderly.
מידע נוסף על מנגנוני גיבוי
חלק הגיבוי יכול להיות מאוחסן כקובץ מוצפן בסיסמה או דרך גורם חברתי (אותו OAuth). במקרה של אובדן כל המכשירים, המשתמש מאמת את עצמו דרך הספק ומאשר את סיסמת הגיבוי — זה משחזר את הגישה. המהנדסים שלנו עוזרים להגדיר אסטרטגיית גיבוי אופטימלית לקהל שלכם.
מה כלול בעבודה
- בחירת תצורת Web3Auth (מספר חלקים, סף, גיבוי)
- הגדרת ספקי OAuth (Google, Apple, Twitter, Discord, GitHub)
- יישום ממשק משתמש: מודאל מוכן או ממשק מותאם לחלוטין
- אינטגרציה עם מערכת הרשאות קיימת (JWT, סשנים)
- קוד ב-TypeScript/React/Vue עם תמיכה ב-ethers.js, viem, wagmi
- תיעוד מנהלים ללוח הבקרה של Web3Auth
- בדיקת תרחישי אבטחה (שחזור, ביטול מפתחות)
- אחריות: אנו תומכים בקוד למשך 3 חודשים לאחר האינטגרציה
לוחות זמנים ועלות
| שלב | זמן |
|---|---|
| אינטגרציה בסיסית (Modal) | 1-2 ימים |
| White-label (NoModal) | 1-2 שבועות |
| מחזור מלא + קצה אחורי | 2-4 שבועות |
העלות מחושבת באופן אישי — תלויה במורכבות הממשק, מספר הספקים ודרישות האבטחה. אנו מפיקים הערכת פרויקט תוך יום אחד: שלחו תיאור של ה-dApp שלכם וקהל היעד. קבלו ייעוץ ממהנדס שהטמיע Web3Auth ביותר מ-12 dApps, כולל פלטפורמות DeFi ושווקי NFT. הניסיון שלנו — 5 שנים ב-Web3, יותר מ-30 אינטגרציות מוצלחות. אנו מבטיחים פעילות יציבה ב-mainnet ותמיכה בתקנים חדשים (ERC-4337, EIP-3074).
רוצים להסיר את חסם הכניסה למשתמשים שלכם? צרו קשר — אנו נבחן את הפרויקט שלכם ונציע ארכיטקטורה סוהרת.







