במסמך הזה מוסבר איך להשתמש ב-Credential Manager כדי לקבל כתובת אימייל מאומתת באמצעות הצפנה ממכשיר של משתמש. התהליך הזה מייתר את הצורך של משתמשי האפליקציה לאמת את כתובת האימייל שלהם באמצעות סיסמאות חד-פעמיות (OTP) או קישורים חד-פעמיים לכניסה.
במסמך הזה מוסבר על התחומים הבאים:
- תאימות ל-Android
- חוויית משתמש
- חשבונות נתמכים
- ההשלכות על יכולת המסירה של אימיילים
- השוואה לכניסה באמצעות חשבון Google
המדריך הזה מבוסס על ההנחה שאתם מכירים את המושגים הבאים:
מיומנויות ב-Android
הצגה ב-GitHubאחזור כתובת אימייל מאומתת
android skills add verified-emailתאימות ל-Android
התכונה הזו נתמכת בניידים, בטאבלטים ובמכשירים מתקפלים עם Android מגרסה 9 (רמת API 28) ומעלה. הגרסה המינימלית הנדרשת של Google Play Services (GMS) היא 25.49.x.
חוויית משתמש
בקטעים הבאים מתוארים חוויית המשתמש במהלך תהליך האימות, הצורך לכלול שיטות אימות חלופיות וחוויית המשתמש המומלצת לתרחישים שונים לדוגמה.
תהליך האימות
חוויית המשתמש בשיתוף כתובת אימייל מאומתת היא כזו:
- המשתמש מתמקד בשדה להזנת קלט או לוחץ על כפתור שמפעיל את Credential Manager API. בהתאם לעיצוב המסך, אפשר גם להפעיל את ה-API כשהמסך של האפליקציה נטען.
- מופיע גיליון תחתון עם המידע שישותף עם האפליקציה. אם אין מידע זמין במכשיר, המשתמש רואה הודעת שגיאה כללית.
- אחרי שהמשתמש לוחץ על אישור והמשך, מציגים הודעה על הצלחה או כישלון.
- הערה: אם כתובת האימייל המאומתת שאתם מקבלים לא תואמת למה שאתם מצפים, הודיעו למשתמש על חוסר ההתאמה ובקשו ממנו לנסות שוב עם פרטי כניסה אחרים או לספק שיטת אימות חלופית, כמו באמצעות סיסמאות חד-פעמיות.
- (אופציונלי, מומלץ) אם המשתמש נרשם לשירות שלכם, כדאי לבקש ממנו ליצור מפתח גישה כדי שיהיה לו קל יותר להיכנס לחשבון בהמשך.
- הערה: תהליך אימות האימייל לא מפעיל באופן אוטומטי את יצירת מפתח הגישה. עם זאת, מומלץ מאוד לכלול את השלבים ליצירת מפתח גישה. מפתחות גישה עוזרים למשתמשים להיכנס לחשבון בצורה קלה ומאובטחת יותר, ומבטלים את הצורך באינטראקציה הרגילה של שם משתמש וסיסמה.
לכלול תהליכים ראשיים וחלופיים
כדי להבטיח חוויית משתמש חלקה, כדאי לכלול את האפשרויות הבאות במסכים שדורשים אימות אימייל:
- אפשרות האימות הראשית: שדה אימייל או כפתור שמפעיל את התהליך של Credential Manager API לאימות מהיר.
- אפשרויות אימות חלופיות: קישור או כפתור שמאפשרים למשתמשים "לאמת בדרך אחרת" או "אפשרויות אחרות" להזנה ידנית של כתובת האימייל במקרה של כשלים, כמו חוסר מידע זמין במכשיר או חוסר התאמה בין כתובת האימייל שאוחזרה לבין כתובת האימייל הצפויה. כך המשתמשים יוכלו לנסות לאמת את החשבון באמצעות פרטי כניסה אחרים או על ידי הזנה ידנית של סיסמה חד-פעמית.
תרחישים לדוגמה
בקטעים הבאים מתוארים התרחישים המומלצים לשימוש באימות אימייל, וגם חוויית המשתמש המומלצת.
הרשמה
המשתמשים יכולים ליצור מיד חשבון עם כתובת אימייל מאומתת בלי שלב אימות נפרד. אם רוצים, אפשר לבקש מהמשתמש להוסיף מפתח גישה. אם הם בוחרים להוסיף מפתח גישה, מפעילים את תהליך יצירת מפתח הגישה.
שחזור חשבון
כדי למנוע מהמשתמשים את התסכול שבחיפוש קודי שחזור בתיקיות הספאם, אפשר לאפשר להם לשחזר את החשבון באמצעות כתובת האימייל המאומתת שמאוחסנת באופן מאובטח במכשיר שלהם. בנוסף, כדאי להציע להם ליצור מפתח גישה לשימוש בעתיד.
אימות מחדש לפעולות רגישות
כדי להגן על פעולות רגישות של משתמשים, כמו שינוי הגדרות או עדכון פרטי פרופיל, אפשר לדרוש שלב מהיר של אימות מחדש.
חשבונות נתמכים
אימות אימייל באמצעות Credential Manager תומך רק באימות של חשבונות Google פרטיים. אין תמיכה בחשבונות Workspace ובחשבונות בפיקוח.
אפשר ליצור חשבון Google פרטי עם כתובת אימייל מכל ספק, לא בהכרח @gmail.com. עם זאת, Google מאמתת את החשבונות האלה באופן שונה:
- בחשבונות @gmail.com: Google היא המקור המוסמך, והאימייל ידוע כמאומת.
- בחשבונות שהם לא @gmail.com: Google היא לא המקור המוסמך לכתובות האימייל האלה לטווח הארוך. Google מאמתת את כתובת האימייל כשהחשבון נוצר, אבל הבעלות על כתובת האימייל הזו יכולה להשתנות עם הזמן. לכן, בכתובות שהן לא @gmail.com, כדאי לשקול שלב אימות נוסף, כמו שליחת סיסמה חד-פעמית (OTP), כדי לוודא שלמשתמש עדיין יש גישה לחשבון האימייל.
למידע נוסף על המשמעות של האימות, ראו פרטי כניסה דיגיטליים.
הערה: בנוסף לפרטי האימייל של המשתמש, אתם יכולים לבקש שדות אחרים שלא אומתו, כמו השם הפרטי, שם המשפחה, השם ותמונת הפרופיל של המשתמש בחשבון Google. עם זאת, רק כתובת האימייל מאומתת על ידי Google.
כדי לאמת את מספר הטלפון, קראו את המאמר אימות מספרי טלפון באמצעות פרטי כניסה דיגיטליים. לפתרון של Firebase, ראו אימות מספר טלפון ב-Firebase.
תוקף ועדכניות
המערכת מנפיקה אישורים לאימות (VC) על סמך כתובת האימייל הנוכחית של המשתמש מחשבונות Google הפעילים במכשיר. פרטי הכניסה האלה מונפקים למכשיר מראש, בדרך כלל כשהמכשיר לא בשימוש. יכול להיות שהפרטים האלה יישארו בתוקף למשך כמה ימים, אבל המערכת מבצעת בדיקה ברגע שיתוף פרטי הכניסה כדי לוודא שהחשבון עדיין קיים, נמצא במכשיר וכתובת האימייל תקינה. למעשה, המערכת נותנת עדיפות לסטטוס המיידי של החשבון על פני חלון התוקף של פרטי הכניסה.
כדי להבטיח אותנטיות, חתימת Key Binding (kb) נוצרת בזמן השיתוף, ומשלבת את ה-nonce.
אם המכשיר לא מחובר לאינטרנט או שהחשבון הוסר, התהליך נכשל במקום לספק קוד אימות שפג תוקפו או קוד אימות לחשבון Google לא פעיל.
יכולת מסירת אימיילים
התהליך הזה מאשר את הלגיטימיות של החשבון, אבל לא מבטיח שהאימייל יגיע לתיבת הדואר הנכנס (למשל, יכול להיות שהאימייל יועבר לספאם). סיסמה חד-פעמית היא עדיין השיטה המוחלטת לאישור יכולת המסירה של אימיילים.
השוואה לכניסה באמצעות חשבון Google
למרות ששני הפתרונות, Digital Credentials וכניסה באמצעות חשבון Google, מספקים כתובת אימייל מאומתת, מסלולי המשתמשים ותרחישי השימוש שונים:
- תרחישים לדוגמה: תהליך אימות האימייל של Credential Manager לא משמש רק בתרחישים לדוגמה של הרשמה או כניסה, אלא בכל תרחיש לדוגמה שכולל אחזור של אימייל מאומת. זה יכול לכלול גם שחזור חשבון.
- הרשמה: בתהליך של Credential Manager לא נדרשת הרשמה ל-Google, בניגוד לכניסה באמצעות חשבון Google.
תמיכה בפלטפורמות: התהליך של Credential Manager הוא פתרון ל-Android בלבד.
היקפי הרשאות: בניגוד לכניסה באמצעות חשבון Google, שבה אפשר להשתמש ב-OAuth 2.0 כדי לבקש גישה לנתוני משתמשים (כמו יומן Google או Drive דרך היקפי הרשאות), Digital Credentials API משמש אך ורק לאחזור מאפייני זהות מאומתים. אי אפשר להשתמש בו כדי לבקש היקפי הרשאות נוספים.
השלבים הבאים
כדי להטמיע את התכונה הזו באפליקציה, עיינו במדריך ההטמעה.