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

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

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

מכשירים ניידים

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

Wear OS

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

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

כדי להשתמש ב-Credential Manager ב-Wear OS, צריך לעמוד בדרישות הבאות:

• רמת API מינימלית: minSdkVersion 33 ומעלה
  • כולל תמיכה בסיסמאות, במפתחות גישה ובכניסה באמצעות חשבון Google
• גרסת GMS: כמו שנדרש לאפליקציות לנייד

ממשק המשתמש במכשירי Wear OS:

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

• אימות במכשירים לבישים: Credential Manager
• המלצות לעיצוב ממשק המשתמש ב-Wear OS
• דוגמה ל-Wear Credential Manager

מגבלות

יש כמה מגבלות לשימוש ב-Credential Manager ב-Wear OS:

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

Android XR

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

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

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

כדי להשתמש ב-Credential Manager ב-Android XR, צריך לעמוד בדרישות הבאות:

• רמת API מינימלית: minSdkVersion 34 ומעלה
• גרסת GMS: זהה לגרסה הנדרשת לאפליקציות לנייד
• אמולטור:
  • קובץ אימג' מינימלי של מערכת האמולטור:
    • ‫macOS: תמונה של מערכת Google Play XR ARM 64 v8a, גרסה 7
    • ‫Windows: קובץ אימג' של המערכת Google Play XR Intel x86_64 Atom גרסה 7
  • גרסאות אמולטור גבוהות מ-35.6.11 יציב

כך נראה תהליך הכניסה לחשבון ב-XR:

‫Flows לא נתמך ב-XR

‫Credential Manager ב-Android XR לא תומך בתהליכי אימות שדורשים מכשיר אחר כדי לסרוק קוד QR. אפשר לראות את זה במהלך תהליכי הכניסה במשקפי XR ובמהלך בדיקה באמצעות האמולטור.

מידע נוסף על XR זמין במאמר Android XR.

Android TV

מכשירי Android TV הם בדרך כלל מכשירים משותפים, שצופים בהם מרחוק ומנווטים בהם באמצעות שלטים רחוקים עם כפתורי חיצים (D-pad). לפעמים למשתמשים קשה להזין שמות משתמש וסיסמאות בסביבה הזו. ‫Credential Manager מפשט את האימות ב-Android TV באמצעות תמיכה בכניסה באמצעות חשבון Google, בסיסמאות שמורות ובמפתחות גישה שפועלים בכל המכשירים. בטלוויזיה משותפת יש בדרך כלל כמה פרופילים ב-Google, ולכן Credential Manager מתאים את עצמו לסביבה המשותפת הזו. הוא מאחזר ומציג את כל פרטי הכניסה שזמינים במכשיר, במקום להגביל את האפשרויות רק לחשבון הפעיל כרגע.

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

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

אם לאפליקציות לנייד ולאפליקציות טלוויזיה יש את אותו שם חבילה ל-Android ואותו מפתח חתימה, מנהל הסיסמאות של Google מזהה אותן כאותה אפליקציה. לכן, אפשר להציע סיסמה שנשמרה במכשיר נייד ישירות בטלוויזיה בלי להגדיר Digital Asset Links (asset_statements). ‫Digital Asset Links נדרשים רק כשמשתפים פרטי כניסה בין גבולות, למשל בין אפליקציה לאתר, או בין אפליקציות עם שמות חבילות שונים.

כדי להשתמש ב-Credential Manager ב-Android TV, צריך לעמוד בדרישות הבאות:

• רמת API מינימלית: Android 14 (רמת API‏ 34, minSdkVersion 34) ומעלה
• ‫גרסת GMS‏: 2026W30 ואילך
• חומרה למפתחות גישה: נדרש מכשיר נייד משני עם מצלמה ו-Bluetooth כדי לסרוק את קוד ה-QR ולהשלים את התהליך ההיברידי של FIDO.

מגבלות

מכיוון שמכשיר Android TV הוא מכשיר משותף, השימוש ב-Credential Manager בפלטפורמה הזו מוגבל בכוונה כדי להגן על פרטיות המשתמשים והאבטחה:

• אי אפשר ליצור או לאחסן מפתחות גישה באופן מקומי: אי אפשר ליצור או לאחסן מפתחות גישה ישירות בטלוויזיה. מכיוון שאין תמיכה בפרטי כניסה מקומיים, אל תגדירו את preferImmediatelyAvailableCredentials כ-true בבקשות שלכם. אם תעשו את זה, מפתחות גישה במכשירים מקושרים יסוננו ולא יוחזרו פרטי כניסה.
• אין ספקי אישורים של צד שלישי: מערכת Android TV לא תומכת במילוי אוטומטי, ולכן מנהלי סיסמאות של צד שלישי לא זמינים בפלטפורמה. המשתמשים חייבים להשתמש במנהל הסיסמאות של Google.
• אין שחזור של פרטי הכניסה: כניסה אוטומטית למכשירים חדשים באמצעות מידע על שחזור פרטי הכניסה לא נתמכת ב-Android TV.

מידע נוסף על פיתוח ל-TV זמין בסקירה הכללית על Android TV.

Android Automotive OS

מכשירי Android Automotive OS‏ (AAOS) הם מערכות משותפות שמשולבות בכלי רכב. כדי להתאים את Credential Manager ל-AAOS, צריך לתמוך באימות מאובטח (בדרך כלל כשהרכב חונה) ולהתאים לכמה פרופילי משתמשים במכשיר משותף.

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

האימות ב-Android Automotive OS תומך בשיטות הבאות:

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

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

כדי להשתמש ב-Credential Manager ב-Android Automotive OS צריך לעמוד בדרישות הבאות:

• רמת ה-API המינימלית: Android 9 (רמת API‏ 28, ‏ minSdkVersion 28) ומעלה. שחזור מפתח גישה במכשירים שונים דורש Android מגרסה 14 (רמת API‏ 34) ומעלה.
• גרסת GMS: אותה גרסה שנדרשת לאפליקציות לנייד.

מגבלות על בדיקות

כדי לבדוק מפתחות גישה, צריך מכשיר פיזי עם גרסת build של Android Automotive OS בתור הפלטפורמה הראשית. הוראות להגדרה מפורטות במאמר בדיקה באמצעות Android Automotive OS ב-Pixel Tablet. אי אפשר להשתמש באמולטורים כדי לבדוק מפתחות גישה כי הם לא תומכים ב-Bluetooth עם צריכת אנרגיה נמוכה (BLE), שנדרש לתהליך ההיברידי של FIDO.

מגבלות ותהליכים שלא נתמכים

יש מגבלות על השימוש ב-Credential Manager ב-Android Automotive OS:

• אין אחסון או אחזור מקומי של מפתחות גישה: אין תמיכה באחזור ישיר של מפתחות גישה מקומיים כי כלי רכב הם מכשירים משותפים. סנכרון ישיר של מפתחות גישה לרכב יוצר סיכון אבטחה, ולכן צריך להשתמש במפתחות גישה באמצעות תהליך היברידי בין מכשירים.
• אין תמיכה באישורים שזמינים באופן מיידי: אם האפליקציה מבקשת מפתח גישה ומגדירה את preferImmediatelyAvailableCredentials כ-true, ממשק המשתמש של הרכב נסגר מיד ומופיעה השגיאה NoCredentialException. צריך לספק חוויית משתמש מתאימה כגיבוי לתרחיש הזה.
• אין ספקי אישורים של צד שלישי: אין תמיכה במנהלי סיסמאות של צד שלישי ב-Android Automotive OS. המשתמשים צריכים להשתמש במנהל הסיסמאות של Google או בתהליכים היברידיים במכשירים שונים כדי לבצע אימות.
• אי אפשר ליצור סיסמה שמורה: ה-API לא תומך ביצירה ובשמירה של סיסמה שמורה חדשה ישירות מממשק המשתמש של הרכב. יצירת פרטי כניסה מוגבלת למפתחות גישה חדשים באמצעות התהליך ההיברידי של FIDO.

מידע נוסף על פיתוח ל-Automotive OS זמין במאמר סקירה כללית על Android Automotive OS.

מקורות מידע נוספים

• מידע על Credential Manager
• מידע על שחזור פרטי הכניסה
• סקירה כללית על Android TV
• סקירה כללית על Android Automotive OS