כניסה חלקה לחשבון ופרטי כניסה דיגיטליים ב-Android

שלום לכולם,

תודה שהצטרפת אלינו היום.

היום אנחנו שמחים לדבר על העתיד של האימות והזהות הדיגיטלית.

אני טום קולווין.

אני מנהל הטכנולוגיה הראשי של Apptaura, ואני GDE ב-Android. מצטרף אליי צ'יפינג יה, מהנדס בכיר לקשרי מפתחים ב-Android ב-Google.

הסיסמה הוותיקה כבר לא בשימוש.

או לפחות, ככה זה אמור להיות.

היום אדבר איתכם על עולם ללא סיסמאות.

סיסמאות הן נקודת חולשה ידועה בתשתית האבטחה שלנו.

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

כדי לפתור את הבעיה הזו, התעשייה ניסתה לאכוף מורכבות: תווים מיוחדים, מספרים, החלפות חובה.

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

כי סיסמה מורכבת שמשתנה באופן קבוע היא סיסמה שסביר להניח שתיכתב על פתק.

גם אימות דו-שלבי שמבוסס על SMS חשוף ליירוט, כמו החלפת כרטיס SIM.

אבל היום הבעיה הזו נפתרה ברובה.

מפתחות הגישה מבוססים על תקני FIDO ומשתמשים בקריפטוגרפיה של מפתחות ציבוריים ופרטיים.

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

המניפסט שלנו היום הוא פשוט.

הגיע הזמן לעבור לעולם בלי סיסמאות.

והכלים לעשות את זה כבר בידיים שלנו.

כדי לבצע את המעבר הזה ב-Android, אנחנו משתמשים ב-Jetpack Credential Manager.

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

אתם קוראים ל-Credential Manager API, והוא מטפל בממשק המשתמש כדי לבחור את שיטת האימות שהמשתמש רוצה לראות.

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

הוא תומך בכניסה, בהרשמה ובגיבוי של פרטי כניסה.

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

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

הוא נועד לתת למשתמשים שליטה מלאה על הנתונים שלהם ואת החופש לעבור לספקים אחרים בכל שלב.

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

והכי חשוב מבחינתנו, יש לו תהליך ייעודי למפתחות גישה.

כך זה נראה למשתמש במהלך ההרשמה.

האפליקציה שלי מודיעה ל-Credential Manager שאימות באמצעות מפתח גישה זמין, ומספקת לו פרטים שנאספו מה-back-end.

אתם לוחצים על "הרשמה", ו-Credential Manager מציג לכם גיליון תחתון עם בקשה לנעילת המסך.

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

ואז Credential Manager מטפל בעבודת הקריפטוגרפיה המורכבת, כמו יצירת מפתח הגישה בפועל.

הוא שומר את מפתח הגישה ב-Credential Manager שלי, שבמקרה הזה הוא מנהל הסיסמאות של Google, אבל זה יכול להיות גם משהו אחר.

כך נראה הקוד.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

קודם כול, אנחנו יוצרים את האובייקט createPublicKeyCredentialRequest הזה באמצעות הפרטים שה-back-end מספק, כלומר registerRequestJson.

ואז אנחנו מפעילים את ה-method הקסומה, credentialManager.createCredential.

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

שימו לב, אגב, שלא הייתי צריך לכתוב כאן קוד ממשק משתמש בכלל.

Credential Manager מטפל בזה בשבילנו.

זה תהליך הכניסה.

מבחינת המשתמש, התהליך דומה מאוד לתהליך ההרשמה.

צריך לבטל את הנעילה פעם אחת וזהו.

למפתחים, רק קצת שונה.

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

קודם כול, אנחנו מקבלים את פרטי הכניסה מה-back-end כדי ליצור מופע של GetPublicKeyCredential.

אנחנו אומרים ל-Credential Manager באילו סוגים של פרטי כניסה אנחנו תומכים.

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

אבל אנחנו יכולים להוסיף גם סוגים אחרים של פרטי כניסה, אם נרצה.

ואז אנחנו קוראים ל-credentialManager.getCredential ומעבירים את רשימת פרטי הכניסה שביקשנו.

שוב, בלי קוד של ממשק משתמש.

אין צורך לכתוב קוד לממשק המשתמש.

ממשק Credential Manager מטפל בזה בשבילנו.

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

כך נפתרת באופן אוטומטי אחת מבעיות האימות הכי מעצבנות כיום.

שמתם לב?

הוא זוכר את השיטה האחרונה שבה השתמשתי כדי להיכנס לחשבון.

התשובה מוצגת בצורה מסודרת בגיליון תחתון.

אגב, זה לא רק מפריע למשתמש.

זה גורם לחיכוך אמיתי.

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

הנה קוד האפליקציה לדוגמה, שבו אתם יכולים להשתמש כדי לנסות את Credential Manager בעצמכם.

אתם יכולים לראות את התהליכים האלה במכשיר שלכם.

ויש את דוגמאות הקוד הרשמיות של Google בצד שמאל.

הוא מטפל ביצירת מפתחות גישה.

מה לגבי שדרוג משתמשים קיימים עם סיסמאות למפתחות גישה?

כלי יעיל לכך הוא "יצירה מותנית".

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

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

הוא לא מפריע לתהליך העבודה של המשתמש.

הסיסמ-- מפתח הגישה נוצר באופן שקט ונשמר.

מנהל הסיסמאות של Google יציג התראה כדי לאשר שזה קרה.

במנהלי סיסמאות אחרים יכול להיות שהתהליך יהיה שונה.

הקוד של Conditional Create דומה מאוד לקוד של ההרשמה.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

הדגל הקסום הוא isConditional true, מה שמבטיח שהמשתמש לא יראה את ממשק המשתמש הזה.

ומכיוון שהיא פועלת באופן אופורטוניסטי, נשים אותה ב-try-catch.

אנחנו נטפל בשגיאות בלי להפריע למשתמש אם התהליך ייכשל.

אחרי זה מפתח הגישה נשמר ב-Credential Manager של המשתמש, וזמין לשימוש בפעם הבאה.

בנוסף, Credential Manager מאפשר לספקי פרטי כניסה לייבא ולייצא את פרטי הכניסה שלהם בצורה מאובטחת.

כמה קליקים וזהו.

לא צריך להוריד שום דבר.

זה מאפשר יותר גמישות, תוך שמירה על אבטחת המידע.

התהליך נראה כך.

בספק פרטי הכניסה החדש, המשתמש מבקש לייבא את פרטי הכניסה.

לאחר מכן, Credential Manager מטפל בממשק המשתמש של הייבוא, ומאפשר למשתמש לבחור את המקור של נתוני פרטי הכניסה.

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

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

כך הוא יכול לייבא אותו בלי אינטראקציה של המשתמש.

אבל מה קורה אם המשתמש מבטל מפתח גישה מהאפליקציה או מהאתר שלו?

במקרה כזה, ספק פרטי הכניסה לא בהכרח יודע שזה קרה.

בפעם הבאה שהם ינסו להיכנס, Credential Manager יציע את מפתח הגישה הלא פעיל, והניסיון שלהם יידחה.

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

עכשיו, באמצעות Signal API, האפליקציה יכולה לסמן את המצבים הספציפיים האלה לספק פרטי הכניסה.

לדוגמה, נניח שמשתמש מנסה להיכנס עם סיסמה שבוטלה.

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

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

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

אבל חשוב לזכור שהמטרה הסופית שלנו היא להפסיק להשתמש בסיסמאות בכלל.

איך Credential Manager עוזר להשיג את המטרה הזו?

הנה תהליך של חמישה שלבים שאנחנו מציעים.

בשני השלבים הראשונים, אתם משדרגים את המשתמשים שמשתמשים בסיסמאות למפתחות גישה.

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

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

אנחנו יכולים להתחיל להציג אותם בהדרגה באופן בולט יותר ויותר.

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

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

אבל המשתמשים הישנים האלה, זה מי שאנחנו מתמודדים איתו בשלושת השלבים האחרונים האלה.

אנחנו ממליצים למשתמשים במפתחות גישה להסיר את הסיסמאות שלהם.

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

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

ולבסוף, אתם עוברים ממחיקת סיסמאות בהצטרפות למחיקת סיסמאות בביטול הצטרפות.

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

ניתוח הנתונים ייתן לנו ביטחון להסיר לחלוטין את תהליכי הסיסמה מהאפליקציה.

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

הוא נתמך באופן נרחב.

ממשקי ה-API חזקים וחוויית המשתמש מצוינת.

אני ממליץ לך להתחיל לשלב תהליכים של מפתחות גישה עם Credential Manager כבר היום.

התחילו לשדרג את המשתמשים שלכם, ובואו נשאיר את הסיסמאות בעבר.

תודה.

עכשיו אני רוצה להעביר את רשות הדיבור לצ'יפינג, שידבר על השלב הבא באבולוציה של העברת מכשירים וזהות.

מגניב.

בסדר, תודה, תום.

כמו שתום הדגיש, אימות חלק במכשירי המשתמשים הוא קריטי.

אבל מה קורה כשמשתמש מקבל טלפון חדש?

הירידה הגדולה ביותר בתהליך שעובר המשתמש כיום מתרחשת לעיתים קרובות כשהוא עובר בין מכשירים.

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

החל מאפריל 2027, כדי לשמור על יכולות פרסום מלאות ועל חשיפה אופטימלית בחנות Play, האפליקציות ב-Google Play יצטרכו לעמוד בדרישות של כניסה בלחיצה אחת.

מהי כניסה ללא לחיצה?

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

איך מטמיעים את זה?

השיטה העיקרית שאנחנו ממליצים עליה היא להשתמש ב-Restore Credentials API של Android דרך Credential Manager.

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

מומלץ ליצור את המפתח הזה ברקע אחרי שהמשתמש נכנס לחשבון.

בתרשים הזה מוצג משתמש שנכנס לאפליקציה.

לאחר מכן, מפתח השחזור נוצר בזמן שהם משתמשים באפליקציה בשלב כלשהו.

המפתח הזה נשמר באופן מקומי, או בענן אם האפשרות הזו מופעלת.

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

המשתמשים יכולים לבחור אם לשחזר נתונים מהענן או להעביר אותם ממכשיר למכשיר.

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

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

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

כך המשתמש יוכל להתחבר לאפליקציה בלי לפתוח אותה באופן ידני.

חלק מהשותפים שלנו כבר הטמיעו את זה באפליקציה שלהם.

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

חשוב מאוד שהגישה תהיה פשוטה.

כשהמשתמשים עוברים למכשיר חדש, הם מצפים למעבר חלק בלי צורך להתחבר מחדש לאפליקציית Uber או לעבור אימות חד-פעמי שמבוסס על SMS בכל פעם.

התחלופה התכופה הזו של מכשירים מקשה על שימור המשתמשים.

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

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

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

השינוי הזה ייכנס לתוקף באפריל 2027, אז כדאי לסמן את התאריך ביומן.

כדי להתחיל להטמיע את התכונה "שחזור פרטי הכניסה" באפליקציה, אפשר לסרוק את קוד ה-QR הזה או ללחוץ על הקישור כדי לגשת למיומנות "שחזור פרטי הכניסה".

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

עכשיו בואו נסתכל קדימה על השלב הבא של הזהות הדיגיטלית: Digital Credentials API דרך Credential Manager.

בואו נראה מהם אישורי ההסמכה הדיגיטליים ואיך הם עובדים.

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

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

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

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

בתעודות דיגיטליות מעורבים שלושה גורמים: המנפיק, המחזיק והמאמת.

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

בואו נסקור כל אחת מהישויות האלה ואת התפקיד שלה.

הראשון הוא המנפיק, שכמו שהשם מרמז, הוא גורם שמנפיק אישור, בדיוק כמו שהממשלה מנפיקה את הדרכון שלכם.

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

למעשה, כל אחד יכול להיות מנפיק, בין אם מדובר במכון כושר, במלון או אפילו בכם.

אתם רק צריכים ליצור פרטי כניסה ולחתום עליהם.

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

הגורם הבא הוא המחזיק, שנקרא גם ארנק דיגיטלי.

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

הם נשמרים כאפליקציה במכשיר, ואז אפשר להציג אותם לגורמים שמבקשים לראות אותם.

בדומה למנפיקים, כל אחד יכול להיות מחזיק.

למעשה, במקרים רבים אותה ישות מנהלת את המנפיקים ואת המחזיקים.

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

במקרה כזה, אתם גם המנפיקים וגם המחזיקים.

הצד השלישי הוא הגורם המאמת, או הגורם שמבקש את התעודה המזהה הדיגיטלית.

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

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

ב-Android, האינטראקציות בין שלושת הצדדים האלה לבין המשתמש מתואמות דרך Credential Manager באמצעות Digital Credentials API.

המנפיק יכול לקרוא ל-API כדי להנפיק פרטי כניסה למחזיק, אבל זה לא הכרחי אם מדובר באותה ישות.

אחרי שהאישור מונפק, גורם מאמת יכול לשלוח קריאה ל-API כדי לבקש את האישור.

‫Credential Manager מתאים את הבקשה לכל בעלי האישורים הזמינים ומציג אותם למשתמש כדי שיבחר את האישור וייתן הסכמה.

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

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

עכשיו אתם בטח חושבים: איך בדיוק מאובטחים המסמכים הדיגיטליים?

למעשה, יש אמצעי אבטחה מובנים בכל שלב בתהליך, ונעבור על כמה מהם עכשיו.

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

איך אפשר לאמת את זה?

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

בעל הארנק שולח את אישור הארנק, בדרך כלל כשרשרת אישורים שניתן לאמת.

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

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

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

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

Credential Manager משתמש במטא-נתונים האלה כדי לקבוע אילו בעלי אישורים להציג כשגורם מאמת שולח בקשה לאישור.

נתוני משתמשים אמיתיים אף פעם לא נרשמים ב-Credential Manager או נחשפים ל-Google.

גם כש-Credential Manager בוחר אילו ארנקים להציג למשתמש, התוכן של כל ארנק לא נחשף באותו שלב.

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

כמו שאתם אולי זוכרים, מחזיק הוא רק אפליקציה, אז האפליקציה מופעלת.

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

ל-Google אין גישה לנתוני פרטי הכניסה עצמם.

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

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

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

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

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

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

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

עכשיו, אחרי שהסברנו איך פועלת האבטחה של התעודות המזהות הדיגיטליות, נפרט כמה מתרחישי השימוש בתעודות מזהות דיגיטליות שזמינים כיום דרך Digital Credentials API ב-Android.

השיטה הראשונה שאסביר עליה נקראת אימות אימייל.

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

המשמעות היא שהמשתמשים לא צריכים לצאת מהאפליקציה, אלא רק להביע הסכמה בלחיצה אחת בגיליון התחתון המוכר של Credential Manager.

הנה הקלטה של הדגמה של ה-API בפעולה.

זו אפליקציה לדוגמה שמטמיעה אימות אימייל באמצעות Digital Credentials API.

כשאני לוחץ על "בקשה לאימות כתובת אימייל", Credential Manager מבקש תעודה דיגיטלית לאימות כתובת אימייל מהמחזיקים במכשיר שיש להם תעודה מהסוג הזה.

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

זו אחת מכתובות האימייל שהמשתמש מחובר אליהן במכשיר.

למעשה, במקרה הזה Google היא גם המנפיקה וגם המחזיקה של התעודה הדיגיטלית.

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

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

מבחינת המשתמש, זה פשוט כמו להביע הסכמה ואז לעבור למסך הבא.

כדי לנסות את זה, אתם יכולים לעבור לדוגמה שלנו ב-GitHub ולהתקין אותה במכשיר שלכם.

כדאי לנסות להשתמש בה במכשיר פיזי, וחשוב לזכור שצריך להיכנס לחשבון Gmail אחד לפחות במכשיר.

אז אתן עוד קצת זמן אם אנשים מעוניינים.

טוב.

נשמע מרגש, נכון?

כשאתם חושבים על אימות אימייל, מהי שיטת האימות הבאה שעולה לכם בראש?

נכון, אימות מספר הטלפון.

‫Digital Credentials API תומך באופן מובנה גם ב-Phone Number Verification, וכך מסיר את החיכוך ונקודת החולשה של סיסמאות חד-פעמיות ב-SMS.

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

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

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

אז איך ההגדרה הזו עובדת?

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

כשגורם מאמת, כמו האפליקציה שלכם, מבקש את מספר הטלפון של המשתמש, הוא מאחזר אותו מ-Google Telephony באמצעות קריאה ל-Digital Credentials API.

יכול להיות שאתם תוהים איך החיוב עובד.

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

זה קורה אחרי שמספר הטלפון מאוחזר מ-Google Telephony, שם הוא מאוחסן במצב מוצפן.

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

היתרון הגדול הוא שהספק יחייב אתכם רק על אימותים שהושלמו בהצלחה, שמועברים באמצעות חבילת הגלישה או Wi-Fi, והם הרבה יותר אמינים מ-SMS.

כאן יש הדגמה של אימות מספר הטלפון בפעולה, באמצעות Firebase בתור אגרגטור של ספקי סלולר.

האפליקציה מבקשת את מספר הטלפון של המשתמש כחלק מתהליך הכניסה.

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

אחרי שהמשתמש מאשר את הבחירה שלו, ההחלפה מתבצעת ברקע.

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

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

פשוט תנו לזה להסתיים כדי שתוכלו לראות את ההשלמה פעם נוספת.

לכן מספר הטלפון מופיע במסך האחרון.

וזהו.

עברנו על הרבה נושאים היום.

קודם בדקנו איך להשתמש ב-Credential Manager כדי לשפר את ההטמעה של מפתחות הגישה ולעבור לעולם ללא סיסמאות.

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

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

הדרישה הזו תהפוך לחובה בחנות Play באפריל 2027, אז כדאי לסמן את התאריך ביומן.

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

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

כל מה ששיתפנו היום זמין ומוכן לשימוש.

העתיד של הזהות ב-Android כבר כאן, והוא מרגש יותר מתמיד.

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

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

תודה.