עזרה למשתמשים לנהל מפתחות גישה בצורה יעילה

מפתחות גישה הם חלופה מהירה, קלה ומאובטחת יותר לסיסמאות, שמספקת אבטחה משופרת ונוחות למשתמש. כדי לממש את מלוא הפוטנציאל של מפתחות הגישה, צריך להשקיע מחשבה רבה בחוויית המשתמש שקשורה לניהול שלהם. במסמך הזה מפורטות הנחיות ותכונות אופציונליות לתכנון מערכת ניהול של מפתחות גישה אינטואיטיבית, מאובטחת וחזקה.

ניהול כמה מפתחות גישה

לאפשר למשתמשים להוסיף כמה מפתחות גישה ולהשתמש ביותר מספק אחד. אבל אל תאפשרו להם להוסיף יותר ממפתח גישה אחד לאותו חשבון אצל אותו ספק. אם משתמש מאבד את הגישה לספק אחד, למשל אם הפלטפורמה לא תומכת בו או שהמשתמש מאבד את הגישה אליו, הוא עדיין יכול להיכנס באמצעות מפתח גישה אחר מספק אחר. כך אפשר לצמצם את הסיכון לנעילת חשבונות. חשוב לוודא שמסד הנתונים תומך באחסון של כמה מפתחות גישה לכל משתמש.

הצגת רשימה של מפתחות גישה רשומים

באתר או באפליקציה שלכם צריכים להופיע מפתחות גישה רשומים ברשימת פרטי המפתחות, כדי לעזור למשתמשים לנהל אותם בצורה יעילה. צילום המסך הזה מראה איך יכול להיראות דף ייעודי לניהול מפתחות גישה. הוא מראה איך משתמשים יכולים ליצור מפתחות גישה בכמה פלטפורמות, ומספק מקום מרכזי לניהול שלהם.

דוגמה לדף ניהול של מפתח גישה עם שיטות מומלצות.
דוגמה לדף ניהול של מפתחות גישה שמוצגות בו שיטות מומלצות.

ריכזנו כאן כמה מהפרטים והתכונות הנפוצים שאתרים ואפליקציות יכולים להציג לגבי מפתח גישה:

  • שם מפתח הגישה: הצגת שם מפתח הגישה שסופק בזמן הרישום. באופן אידיאלי, השם הזה תואם לספק של מפתח הגישה שבו הוא נוצר על סמך ה-AAGUID. אם לא נמצא ספק מפתח גישה תואם, אפשר לתת לו שם לפי פרטי המכשיר על סמך מחרוזת סוכן המשתמש.
  • לוגו של ספק מפתח הגישה: הצגת הלוגו של ספק מפתח הגישה. כך המשתמש יכול לזהות את מפתח הגישה שהוא רוצה לנהל.
  • חותמת הזמן של מועד היצירה של מפתח הגישה ומועד השימוש האחרון בו: גם תיעוד והצגה של חותמת הזמן של מועד היצירה של מפתח הגישה ושל חותמת הזמן של מועד השימוש האחרון בו יכולים לעזור למשתמש לזהות את מפתח הגישה שהוא רוצה לנהל.
  • אינדיקטור ללא סנכרון: מפתחות הגישה מסונכרנים כברירת מחדל, אבל יכולת הסנכרון של ספקי מפתחות הגישה עדיין מתפתחת. בלבול נפוץ הוא מפתח גישה שלא מסתנכרן למרות הציפייה של המשתמש. הצגת ההודעה על כך שמפתח גישה לא יכול לסנכרן יכולה לעזור למשתמשים להבין את הבלבול הזה.
  • לחצן מחיקה: מאפשר למשתמשים למחוק את מפתח הגישה. פרטים נוספים זמינים במאמר אישור מחיקה של מפתח גישה.
  • לחצן עריכה: משתמשים רבים מעריכים את האפשרות לשנות את השם של מפתח גישה. לדוגמה, כשיש כמה מפתחות גישה מאותו ספק מפתחות גישה, אבל עם חשבונות ספק שונים. נניח ששמרתם כמה מפתחות גישה בחשבונות Google שונים. אם תאפשרו למשתמש לשנות את שם מפתח הגישה, הוא יוכל לשנות אותו לשם שהוא רוצה.
  • דפדפן, מערכת הפעלה או כתובת IP של הכניסה האחרונה: אפשר לספק פרטים על הכניסה האחרונה כדי לעזור למשתמש לזהות כניסות חשודות. הדפדפן, מערכת ההפעלה או כתובת ה-IP (או המיקום) שבהם נעשה שימוש כדי להיכנס לחשבון יכולים לספק מידע שימושי.

מתן הרשאה למחיקת מפתח גישה

המשתמשים יכולים למחוק מפתח גישה. כך הם יכולים לנקות את הרשימה, למשל, כשמשתמש עובר למכשיר חדש אבל מפתח הגישה המשויך קשור למכשיר הישן. הוא גם עוזר במקרה שבו תוקף מפרץ לחשבון משתמש ויוצר מפתח גישה לשימוש עתידי.

שליחת אות על רשימת מפתחות הגישה המעודכנת

מחיקת מפתח גישה מסירה את פרטי הכניסה ואת המפתח הציבורי שלו ממסד הנתונים של השרת. כך מפתח הגישה ייעלם מרשימת מפתחות הגישה הרשומים, ויראה למשתמש שהוא נמחק. עם זאת, בפועל הוא מוסר רק מהשרת, ומפתח הגישה שנשמר אצל ספק מפתחות הגישה עדיין נשאר, מה שעלול לגרום לבלבול. בפעם הבאה שהמשתמש ינסה להיכנס לחשבון, מפתח הגישה שהוסרו עדיין יופיע כאפשרות כניסה. אבל האימות באמצעותו נכשל, כי המפתח הציבורי התואם כבר נמחק מהשרת.

כדי למנוע בלבול, חשוב לשמור על עקביות בין מפתח הגישה של ספק מפתחות הגישה לבין המפתח הציבורי בשרת. כדי לעשות זאת, צריך לשלוח לספק מפתחות הגישה אות על הרשימה המעודכנת של מפתחות הגישה. אם הדפדפן וספק מפתח הגישה תומכים ב-Signal API, הם יכולים לעדכן את רשימת מפתחות הגישה ולמחוק מפתחות גישה מיותרים. אם האפליקציה לא תומכת ב-API, כדאי לעודד את המשתמש למחוק את מפתח הגישה באופן ידני.

מחיקת מפתח הגישה האחרון

אם משתמש מנסה למחוק את מפתח הגישה האחרון שנותר לו לחשבון מסוים, חשוב לוודא שהוא מבין שהוא יצטרך להיכנס לחשבון באמצעות אפשרות אחרת, עם יותר חיכוכים ועם רמת הגנה נמוכה יותר. אם זוהי שיטת הכניסה היחידה שלהם לאתר, הם לא יוכלו להיכנס שוב. עליכם להסביר למשתמשים איך להיכנס בפעם הבאה, למשל באמצעות שיטת גיבוי אם היא זמינה, או לבקש מהם לרשום מפתח גישה נוסף לפני שהם ממשיכים. זו הזדמנות טובה לקבל משוב על הסיבה שבגללה הם בחרו לא להשתמש במפתח גישה.

אפשר ליצור מפתחות גישה חדשים

יש הזדמנויות ליצור מפתחות גישה לאורך התהליך של המשתמש (למשל, מיד אחרי הכניסה לחשבון), אבל חשוב מאוד שיהיה מרכז מרכזי שבו המשתמשים תמיד יוכלו ליצור מפתחות גישה חדשים, למחוק מפתחות גישה ולנהל אותם. המסך לניהול מפתחות הגישה הוא המקום הטוב ביותר לעשות זאת.

כדי ליצור תהליך כניסה של משתמש עם מפתח גישה, פועלים לפי ההוראות במדריך למפתחים בנושא יצירת מפתח גישה לכניסות ללא סיסמה. כדי לשפר את האבטחה, מומלץ לאפשר למשתמשים ליצור מפתח גישה באסימון אבטחה לחומרה. משתמשים שמוכנים לנהל מפתחות גישה הם בדרך כלל משתמשים בעלי ידע או ניסיון רב יותר, ולכן מתן אפשרות ליצור מפתח גישה במפתח האבטחה שלהם מאפשר להם גמישות רבה יותר.

כדי לאפשר שמירת מפתחות גישה באסימון אבטחה פיזי, משאירים את הערך של authenticatorSelection.authenticatorAttachment לא מוגדר במקום להגדיר אותו ל-"platform" בבקשה ליצירת מפתח גישה. כך הדפדפן מקבל גם מאמתי פלטפורמה (מכשיר) וגם מאמתי נדידה (מפתח אבטחה), וחוויית המשתמש לא שונה באופן משמעותי מאשר אם מאפשרים רק מאמתי פלטפורמה. האפשרות ליצור מפתח גישה במפתח אבטחה מופיעה כאפשרות משנית.

רשימת המשימות

  • לאפשר למשתמשים לנהל מפתחות גישה בדף ניהול מפתחות הגישה.
  • תמיכה ברישום של כמה מפתחות גישה.
  • המשתמשים יכולים להוסיף בדף הניהול סוגים חדשים וגמישים של מפתחות גישה.
  • מציגים את שם מפתח הגישה.
  • לציין אם מפתח הגישה ניתן לסנכרון או לא.
  • המשתמשים יכולים להסיר מפתח ציבורי מהשרת.
  • לשלוח אות לרשימת מפתחות הגישה כשמפתח ציבורי משויך מוסר מהשרת.

מדריכים אחרים בנושא UX