פורסם: 21 במאי 2026
ב-Google I/O 2026, דיברנו על אינטרנט שבו הכניסה לחשבון היא לא מטלה. היא צריכה להיות נקודת כניסה מאובטחת ופשוטה שבאמת גורמת למשתמשים להרגיש בטוחים. בפוסט הזה נסביר איך לתקן את תהליכי ההרשמה בחשבון, לצמצם את החיכוך ולהגן על אנשים מההתחלה.
גישה מהירה
- למה מודרניזציה חשובה
- ייעול תהליך יצירת החשבון
- אימות מאפיינים ללא הפרעה
- איך מטמיעים מפתחות גישה לכניסה חלקה לחשבון
- אימוץ אסטרטגי של מפתחות גישה
- ניהול מפתחות גישה ושחזור עמיד
למה מודרניזציה חשובה
תהליכים עם חיכוך גבוה (כמו טפסים מסובכים להרשמה, לולאה מעצבנת של 'שכחתי את הסיסמה' או קיר של לחצני כניסה) הורסים את חוויית המשתמש. הם "מפריעים למשתמשים להתמקד" וגורמים להם לעזוב את האתר. סיסמאות רגילות וסיסמאות חד-פעמיות (OTP) גם הן משאירות את האנשים חשופים לפישינג.
כל שנייה של חיכוך היא הזדמנות למשתמש לנטוש את התהליך. מודרניזציה של האימות מגנה על המערכות ועל המשתמשים. כשמייעלים כל נקודת מגע במסלול להמרת הלקוח, שיעורי ההמרה עולים באופן טבעי. לדוגמה, אחרי הטמעת מפתחות גישה, חברת pixiv השיגה שיעור הצלחה של 99% בכניסה לחשבון (שיפור של 29% לעומת סיסמאות). המעבר מפרטי כניסה חלשים מאפשר לבצע פעולות מהר יותר ובצורה בטוחה יותר.
דרך קלה יותר ליצור חשבונות
האינטראקציה הראשונה של המשתמש עם האפליקציה קובעת את הטון. השלב הראשון בשיפור ההטמעה והבטיחות הוא ייעול תהליך יצירת החשבון.
איחוד זהויות כשיטה העיקרית ליצירת חשבונות
אתם יכולים לאפשר למשתמשים לדלג על טופסי יצירת החשבון המייגעים באמצעות איחוד זהויות, שמאפשר למשתמשים להירשם באמצעות ספק מהימן כמו Google. כך תוכלו לספק חוויית הרשמה חזקה ויעילה שתאפשר למשתמשים להיכנס לאפליקציה בלי הצורך לבצע את תהליך ההרשמה הרגיל.
פדרציה מאפשרת למשתמשים לא להקליד את השם או כתובת האימייל שלהם באופן ידני. מכיוון שהספק כבר אימת אותם, אתם יכולים לדלג על שלבים מיותרים כדי לאמת אותם באופן עצמאי, וכך לאפשר ליותר אנשים להיכנס.
בנוסף, אימוץ פתרון של זהות מאוחדת מאפשר לכם לרשת את רמת האבטחה של ספק זהויות (IdP) ייעודי. מכיוון שספקי זהויות מתמחים בזהות ובאבטחה, הסתמכות על התשתית שלהם מבטלת את הסיכון של בניית אימות מאפס.
אימוץ Federated Credential Management (FedCM) API
אם אתם פועלים כספק זהויות, מומלץ להטמיע את FedCM API. האינטראקציה מתבצעת דרך ממשק המשתמש של הדפדפן, שמגן על הפרטיות על ידי מניעת מעקב, ומאפשר למשתמשים להיכנס לחשבון בלחיצה אחת. בנוסף, ממשק המשתמש נראה פחות עמוס כי מוצגים בו רק חשבונות רלוונטיים.
התבנית 'איחוד ואז שדרוג'
השיטה 'איחוד ואז שדרוג' משלבת את המהירות של איחוד עם האבטחה לטווח ארוך של מפתחות גישה. אם מבקשים מפתח גישה מיד אחרי הרשמה מאוחדת, הכניסה הבאה של המשתמש לחשבון תהיה עמידה בפני פישינג כבר מהיום הראשון.
אופטימיזציה של טפסים למילוי אוטומטי
אם יש צורך בטפסים ידניים, צריך להשתמש במאפיינים תיאוריים name וid ובערכים autocomplete נכונים כדי לאפשר לדפדפן למלא את השדות בשביל המשתמש. כך מפחיתים את העומס הקוגניטיבי ואת הסיכוי לטעויות הקלדה במהלך תהליך ההרשמה. בשיטות המומלצות ליצירת טופס הרשמה יש פרטים נוספים על אופטימיזציה של טפסים.
<label for="email">Email</label>
<input type="email" id="email" name="email" autocomplete="email">
<label for="password">New Password</label>
<input type="password" id="password" name="password" autocomplete="new-password">
אימות מאפיינים ללא בעיות
אם המשתמשים צריכים לצאת מהאפליקציה כדי לבדוק קוד באימייל, שיעורי ההמרה יורדים. במעבר הזה בין האפליקציות, אנשים מוסחים ולא חוזרים יותר.
הסבר על פרוטוקול אימות האימייל (EVP)
פרוטוקול אימות האימייל (EVP) הוא תכונה חדשה שמאפשרת לאפליקציה שלכם לקבל כתובת אימייל מאומתת ישירות דרך הדפדפן.
כדי להביע הסכמה לשימוש בתכונה הזו, מוסיפים שדה להזנת קלט מוסתר עם המאפיין autocomplete="email-verification-token" ועם הערך challenge. הדפדפן מנתח את דומיין האימייל מהקלט ומבקש מנפיק האימייל לאמת שלמשתמש יש שליטה באימייל הזה. אחרי שהאימות יסתיים בהצלחה,
הדפדפן יציג טענה מאומתת לגבי כתובת האימייל, והקצה העורפי יוכל לאמת אותה
באופן מיידי. התהליך הזה מתבצע בצורה חלקה מבחינת המשתמש, והוא רואה רק התראה אחרי אימות האימייל.
ה-EVP מסיר את הצורך בחיכוך שמרחיק אנשים (כמו קישורים קסומים או קודי OTP באימייל) לצורך כניסה, הרשמה ואיפוס סיסמה.
<input id="email" type="email" autocomplete="email">
<input type="hidden" name="token" challenge="1234" autocomplete="email-verification-token">
חשוב לדעת שספקי אימייל שונים תומכים ב-EVP. כדאי לבדוק עם הספק הספציפי שלכם אם הוא מתכנן לתמוך ב-EVP. אם יש לכם דומיין מותאם אישית, אתם יכולים לקשר אותו לספק אימייל שתומך גם ב-EVP.
מכיוון שהתכונה הזו עדיין בשלב ניסיוני, נשמח לקבל משוב על מאגר GitHub.
Digital Credentials API
לפרטים רגישים כמו שם חוקי או גיל, Digital Credentials API מספק דרך לבקש נתונים מאומתים מהארנק של המשתמש באמצעות תיווך של הדפדפן, תוך שימוש בחשיפה סלקטיבית. כלומר, אתם יכולים לאמת שמשתמש מסוים הוא מעל גיל מסוים, בלי לקבל את תאריך הלידה המלא או את השם החוקי שלו, וכך לשמור על הפרטיות שלו.
אפשר לעיין במאמר Digital Credentials API: Secure and private identity on the web (ממשק API של אישורים דיגיטליים: זהות מאובטחת ופרטית באינטרנט).
הטמעה של מפתחות גישה לכניסה חלקה לחשבון
מפתחות גישה הם לא רק תחליף לסיסמאות. הם מייצגים שינוי מהותי לקראת אימות חלק ועמיד בפני פישינג.
מצב ממשק משתמש מיידי
מגרסה Chrome 149, זמין מצב ממשק משתמש מיידי. היא מאפשרת לאתר לבדוק פרטי כניסה ברגע שמשתמש עובר לאתר שלכם. אם מפתח גישה או סיסמה זמינים במנהל הסיסמאות, הדפדפן מציג מיד את רשימת החשבונות הזמינים בתיבת דו-שיח לכניסה.
כך המשתמשים לא צריכים לבחור שיטת כניסה. הצעת פרטי הכניסה לחשבון שנבחר באופן יזום יוצרת חוויה חלקה של "הקשה אחת" שמרגישה למשתמש כמו קסם.
const credential = await navigator.credentials.get({
password: true,
uiMode: 'immediate',
publicKey: publicKeyObject,
});
מידע נוסף מופיע במאמר בנושא מצב ממשק משתמש מיידי לכניסה לחשבון.
מילוי אוטומטי של טפסים באמצעות מפתחות גישה: שימוש במילוי אוטומטי של טפסים במהלך המעבר לשימוש במפתחות גישה
למשתמשים באתרים שעוברים מסיסמאות למפתחות גישה, מילוי אוטומטי של טופס עם מפתח גישה מאפשר למפתחות גישה להופיע בהצעות למילוי אוטומטי כשמתמקדים בשדה להזנת קלט. המשמעות היא שאם למשתמש כבר יש מפתח גישה, ברגע שהוא יתמקד בשדה של שם המשתמש בטופס כניסה. אם הם לא יאשרו, הם עדיין יוכלו להשתמש בסיסמה השמורה.
כדי להפעיל את האפשרות הזו, מוסיפים הערה לשדה של שם המשתמש עם autocomplete="username webauthn" ומגדירים את הערך של mediation ל-'conditional' כשמפעילים את navigator.credentials.get().
זהו גשר חשוב במהלך המעבר לעתיד ללא סיסמאות, כי הוא מאפשר למשתמשים להכיר את מפתחות הגישה בממשק מוכר.
רשימת המשימות לאימות באמצעות מפתחות גישה
אימוץ אסטרטגי של מפתחות גישה
הטמעה היא לרוב עניין של תזמון. הצגת בקשה למשתמש ברגע הנכון יכולה להגדיל באופן משמעותי את הסיכוי שהוא ירשום מפתח גישה.
יצירה אוטומטית של מפתחות גישה
אף אחד לא רוצה לעבור על הגדרות האבטחה רק כדי להגדיר שיטת כניסה חדשה. למשתמשים קיימים עם סיסמאות, איך ומתי כדאי להציע למשתמשים לשדרג למפתחות גישה?
כאן נכנס לתמונה היצירה האוטומטית של מפתחות גישה. עם Conditional Create, הדפדפן יכול לשדרג באופן אוטומטי את המשתמשים בסיסמאות למפתחות גישה בדיוק ברגע שמשתמש מתחבר באמצעות מנהל הסיסמאות שלו.
כשמעבירים את הערך mediation: 'conditional' ל-API של navigator.credentials.create(), שמופעל על ידי כניסה מוצלחת לחשבון באמצעות הסיסמה שנשמרה במנהל הסיסמאות, הדפדפן יוצר מפתח גישה חדש באופן מקומי בלי להציג למשתמש מסכי הגדרה נוספים.
המשמעות של הרשמה ללא חיכוך היא שהמשתמשים לא צריכים לקבל החלטה מודעת כדי לשפר את האבטחה שלהם. התהליך מתבצע אוטומטית, וההגנה ניתנת בלי להצריך מאמץ נוסף. לדוגמה, adidas השיגה עלייה של 8% ביצירת מפתחות גישה באמצעות האסטרטגיה הזו של אפס הנחיות.
await navigator.credentials.create({
mediation: 'conditional',
publicKey: { ... },
});
רשימת המשימות לרישום מפתחות גישה
ניהול מפתחות גישה ושחזור גמיש
חשוב שהמשתמשים יוכלו לגשת בקלות לפרטי הכניסה שלהם במכשירים, באתרים ובשירותים שונים. בנוסף, תוכלו לנהל אותם ולוודא שהם יוכלו לשחזר את החשבונות שלהם אם מכשיר יאבד או ייגנב.
עקביות בפלטפורמות שונות
אם יש לכם כמה נכסים (לדוגמה, אפליקציית Android ואתר, או כמה אתרים) שמשתמשים במערכת התחברות משותפת, אתם יכולים לשפר את חוויית המשתמש. עם שיתוף מאובטח של פרטי כניסה, מנהל הסיסמאות יכול להציע למשתמש את פרטי הכניסה הנכונים בכל הנכסים שלכם.
שיתוף חלק של פרטי הכניסה מבוסס על שתי טכנולוגיות: Digital Asset Links לסיסמאות ו-Related Origin Requests למפתחות גישה.
שימוש ב-Digital Asset Links מבטיח שהסיסמאות שנוצרו באינטרנט יהיו זמינות באפליקציית Android, ולהפך. הוא גם מאפשר למנהלי סיסמאות להציע פרטי כניסה שכבר נשמרו בדומיינים שונים שבבעלותכם, שמשתמשים באותו קצה עורפי לאימות.
אפשר להשתמש בבקשות קשורות ממקורות שונים כדי להפוך את מפתחות הגישה לזמינים בדומיינים ובאפליקציות שונים דרך מנהל פרטי הכניסה של המשתמש.
זו עוד דרך לשפר את חוויית הכניסה לחשבון עבור המשתמשים.
מתן אפשרות למשתמשים לנהל את מפתחות הגישה שלהם
כדי ליצור חוויה מתקדמת עם מפתחות גישה, מומלץ ליצור דף ייעודי לניהול מפתחות גישה עם תמיכה בשמות ספקים ברורים, בזמני שימוש ובאמצעי בקרה. כך המשתמשים יכולים לנהל את ההגדרות שלהם בביטחון. שקיפות בונה אמון.
רשימת המשימות לניהול מפתחות גישה
שחזור חשבון עמיד
יכול להיות שהמכשירים יאבדו או ישודרגו. מפתחות גישה הם עמידים מטבעם כי הם מבוססים על הגנה ברמת החומרה, ובדרך כלל הם גם מסונכרנים בענן, כך שהמשתמשים יכולים לשחזר אותם במכשיר חדש. עם זאת, אם יש לכם אפשרות חלופית כמו כתובת אימייל מאומתת, אתם יכולים לוודא שהמשתמשים שלכם לעולם לא יאבדו את הגישה לחיים הדיגיטליים שלהם.
במקום להשאיר מישהו בהמתנה לשיחה עם מוקד התמיכה, אפשר להוכיח שהוא הבעלים באמצעות אותות שאתם כבר סומכים עליהם, כמו אימות זהות או אימות כתובת אימייל.
שילוב האותות האלה באסטרטגיית שחזור מאפשר לכם לשחזר את הגישה באופן מיידי. אחרי שהמכשיר יחזור, צריך לרשום מייד מפתח גישה חדש כדי שהמשתמש יהיה מוגן שוב מפני פישינג.
הגנה על סשנים באמצעות DBSC
כדי להגן על המשתמשים מפני פריצה לחשבונות, חשוב גם לשמור על קובצי ה-Cookie של הסשן. פרטי כניסה לסשן לפי מכשיר (DBSC) מאפשרים לקשר סשן לחומרה. השיטה הזו מפחיתה את הסיכון לחטיפת סשן, כי גם אם קובץ Cookie נגנב, רק אותו מכשיר יכול לבקש הנפקה מחדש של קובץ ה-Cookie. כך נוספת עוד שכבת אבטחה לסשן.
DBSC היא תכונה ניסיונית שזמינה עכשיו ב-Windows. מידע נוסף על העדכון הזה זמין בהודעה על פרטי כניסה לסשן לפי מכשיר ב-Windows. בנוסף, אנחנו פועלים להרחבת התמיכה ב-DBSC ל-macOS.
מיומנויות של סוכן עם מפתחות גישה
בפרויקט ההנחיות שלנו בנושא אינטרנט מודרני כללנו מיומנויות בנושא מפתחות גישה שמתייחסות להיבטים רבים שמתוארים בפוסט הזה. בקרוב נפרסם פוסט בבלוג בנושא מיומנויות של מפתחות גישה.
רוצים לעזור לנו לבנות את העתיד של האימות?
כדאי לעיין במדריכים המפורטים שלנו ולהתחיל בתהליך המודרניזציה עוד היום: