תאריך פרסום: 15 במאי 2025
מפתחות גישה הופכים במהירות לחלופה מאובטחת, קלה ומהירה יותר לסיסמאות, ומציעים אבטחה משופרת ונוחות למשתמשים. כדי לממש את מלוא הפוטנציאל של מפתחות הגישה, צריך להקדיש מחשבה רבה לחוויית המשתמש שקשורה לניהול שלהם. במסמך הזה מפורטות הנחיות ותכונות אופציונליות לעיצוב מערכת אינטואיטיבית, מאובטחת ויציבה לניהול מפתחות גישה.
ניהול של כמה מפתחות גישה
לאפשר למשתמשים להוסיף כמה מפתחות גישה ולהשתמש ביותר מספק אחד. אבל אל תאפשרו להם להוסיף יותר ממפתח גישה אחד לאותו חשבון אצל אותו ספק. אם משתמש מאבד את הגישה לספק אחד, למשל אם הפלטפורמה לא תומכת בו או שהמשתמש מאבד את הגישה אליו, הוא עדיין יכול להיכנס באמצעות מפתח גישה אחר מספק אחר. ההגדרה הזו מפחיתה את הסיכון לנעילת החשבון. מוודאים שמסד הנתונים תומך באחסון של כמה מפתחות גישה לכל משתמש.
הצגת רשימה של מפתחות גישה רשומים
כדי לעזור למשתמשים לנהל את מפתחות הגישה שלהם בצורה יעילה, באתר או באפליקציה שלכם צריכה להיות רשימה של מפתחות הגישה הרשומים עם פרטים על כל מפתח. צילום המסך הזה ממחיש איך יכול להיראות דף ייעודי לניהול מפתחות גישה. הוא מראה איך משתמש יכול ליצור מפתחות גישה בפלטפורמות שונות, ומספק מקום מרכזי לניהול שלהם.
ריכזנו כאן כמה פרטים ותכונות נפוצים שאפשר לראות באתרים ובאפליקציות לגבי מפתח גישה:
- שם מפתח הגישה: השם של מפתח הגישה שניתן בזמן הרישום. השם הזה צריך להיות זהה לשם של ספק מפתחות הגישה שבו הוא נוצר על סמך ה-AAGUID. אם לא נמצא ספק מפתחות גישה תואם, אפשר לתת לו שם לפי פרטי המכשיר על סמך מחרוזת User-Agent.
- הלוגו של ספק מפתחות הגישה: הצגת הלוגו של ספק מפתחות הגישה. כך המשתמש יכול לזהות את מפתח הגישה שהוא רוצה לנהל.
- חותמת זמן של מתי נוצר מפתח הגישה ומתי נעשה בו שימוש בפעם האחרונה: תיעוד והצגה של חותמת הזמן של יצירת מפתח הגישה ושל חותמת הזמן של השימוש האחרון יכולים גם לעזור למשתמש לזהות את מפתח הגישה שהוא רוצה לנהל.
- אינדיקטור לחוסר סנכרון: מפתחות גישה מסונכרנים כברירת מחדל, אבל יכולת הסנכרון של ספקי מפתחות הגישה עדיין מתפתחת. בלבול נפוץ הוא כשמפתח גישה לא מסתנכרן למרות הציפייה של המשתמש. הצגת חוסר היכולת של מפתח גישה לסנכרון יכולה לעזור למשתמשים להבין את הבלבול הזה.
- לחצן המחיקה: מאפשר למשתמשים למחוק את מפתח הגישה. פרטים נוספים זמינים במאמר בנושא איך מאפשרים מחיקה של מפתח גישה.
- לחצן עריכה: משתמשים רבים מעריכים את האפשרות לשנות את השם של מפתח הגישה. לדוגמה, אם יש כמה מפתחות גישה מאותו ספק מפתחות גישה, אבל הם משויכים לחשבונות שונים אצל הספק. תארו לעצמכם שאתם שומרים כמה מפתחות גישה בחשבונות Google שונים. אם מאפשרים למשתמש לשנות את השם של מפתח הגישה, הוא יכול לשנות אותו לשם שהוא אוהב.
- הדפדפן, מערכת ההפעלה או כתובת ה-IP של הכניסה האחרונה: אפשר לספק פרטים על הכניסה האחרונה כדי לעזור למשתמש לזהות כניסות חשודות. הדפדפן, מערכת ההפעלה או כתובת ה-IP (או המיקום) ששימשו לכניסה לחשבון יכולים לספק מידע חשוב.
אפשרות למחוק מפתח גישה
המשתמשים יכולים למחוק מפתח גישה. כך הם יכולים לסדר את הרשימה, למשל, אם משתמש עובר למכשיר חדש אבל מפתח הגישה המשויך קשור למכשיר הישן. היא גם מועילה במקרים שבהם תוקף משתלט על חשבון משתמש ויוצר מפתח גישה לשימוש עתידי.
סימון של רשימת מפתחות הגישה המעודכנת
מחיקת מפתח גישה מסירה את רשומת פרטי הכניסה והמפתח הציבורי שלו ממסד הנתונים של השרת. כך מפתח הגישה ייעלם מרשימת מפתחות הגישה הרשומים, והמשתמש יראה שמפתח הגישה נמחק. אבל בפועל, היא מוסרת רק מהשרת, ומפתח הגישה שמאוחסן אצל ספק מפתחות הגישה נשאר, וזה עלול לגרום לבלבול. בפעם הבאה שהמשתמש ינסה להיכנס לחשבון, מפתח הגישה שהוסר עדיין יופיע כאפשרות כניסה. אבל האימות באמצעות המפתח הזה ייכשל, כי המפתח הציבורי התואם כבר נמחק מהשרת.
כדי למנוע בלבול, חשוב לשמור על עקביות בין מפתח הגישה אצל ספק מפתחות הגישה לבין המפתח הציבורי בשרת. כדי לעשות את זה, צריך לשלוח לספק מפתחות הגישה את הרשימה המעודכנת של מפתחות הגישה. אם הדפדפן וספק מפתחות הגישה תומכים ב-Signal API, הם יכולים לעדכן את רשימת מפתחות הגישה ולמחוק מפתחות גישה מיותרים. אם הם לא תומכים ב-API, צריך לעודד את המשתמש למחוק את מפתח הגישה באופן ידני.
מחיקת מפתח הגישה האחרון
אם משתמש מנסה למחוק את מפתח הגישה האחרון שנותר לו בחשבון מסוים, חשוב לוודא שהוא מבין שהוא יצטרך להיכנס לחשבון באמצעות אפשרות אחרת שדורשת יותר מאמץ ועלולה לספק הגנה פחות טובה. אם זו שיטת הכניסה היחידה שלהם לאתר שלכם, הם לא יוכלו להיכנס שוב. להסביר למשתמשים איך הם יכולים להיכנס בפעם הבאה, למשל באמצעות שיטת גיבוי אם היא זמינה, או לבקש מהם לרשום מפתח גישה נוסף לפני שהם ממשיכים. זו הזדמנות טובה לקבל משוב על הסיבות לכך שהם בחרו לא להשתמש במפתח גישה.
אפשר יצירת מפתחות גישה חדשים
יש הזדמנויות ליצור מפתחות גישה לאורך כל התהליך של המשתמש (למשל, מיד אחרי הכניסה לחשבון), אבל חשוב שיהיה מרכז שבו המשתמשים יכולים תמיד ליצור מפתחות גישה חדשים, למחוק מפתחות גישה ולנהל אותם. הכי טוב לעשות את זה במסך לניהול מפתחות גישה.
כדי ליצור תהליך משתמש של מפתח גישה, פועלים לפי ההוראות במדריך למפתחים בנושא יצירת מפתח גישה לכניסה ללא סיסמה. כדי להגביר את האבטחה, כדאי לאפשר למשתמשים ליצור מפתח גישה באסימון אבטחה פיזי. משתמשים שמוכנים לנהל מפתחות גישה הם בדרך כלל בעלי ידע או ניסיון רב יותר, ולכן כדאי לאפשר להם ליצור מפתח גישה במפתח האבטחה שלהם כדי לשפר את הגמישות.
כדי לאפשר שמירת מפתחות גישה בטוקן אבטחה פיזי, צריך להשאיר את הערך של authenticatorSelection.authenticatorAttachment לא מוגדר במקום להגדיר אותו ל-"platform" בבקשה ליצירת מפתח גישה. כך הדפדפן מקבל גם אמצעי אימות של הפלטפורמה (המכשיר) וגם אמצעי אימות ניידים (מפתח אבטחה), בלי שחוויית המשתמש תהיה שונה באופן משמעותי מהמצב שבו מותר רק אמצעי אימות של הפלטפורמה. האפשרות ליצור מפתח גישה במפתח אבטחה מופיעה כאפשרות משנית.
רשימת המשימות
- המשתמשים יכולים לנהל מפתחות גישה בדף לניהול מפתחות גישה.
- תמיכה ברישום של כמה מפתחות גישה.
- המשתמשים יכולים להוסיף סוגים חדשים וגמישים של מפתחות גישה בדף הניהול.
- הצגת השם של מפתח הגישה.
- מציינים אם מפתח הגישה ניתן לסנכרון או לא.
- המשתמשים יכולים להסיר מפתח ציבורי מהשרת.
- סימון הרשימה של מפתחות הגישה כשמסירים מהשרת מפתח ציבורי משויך.
מדריכים אחרים בנושא UX
- מדריכים כלליים בנושא חוויית משתמש עם מפתחות גישה
- מדריכים ל-Android