משתמשי Identity Platform בפרויקטים
אובייקט המשתמש ב-Identity Platform מייצג חשבון משתמש שנרשם לאפליקציה בפרויקט Google Cloud. בדרך כלל יש לאפליקציות הרבה משתמשים רשומים, וכל האפליקציות בפרויקט Google Cloudמשתפות מסד נתונים של משתמשים.
מופעי משתמשים הם בלתי תלויים במופעי Identity Platform, כך שאפשר להפנות לכמה משתמשים שונים באותו הקשר ועדיין להפעיל כל אחת מהשיטות שלהם.
מאפייני משתמש
למשתמשי Identity Platform יש קבוצה קבועה של מאפיינים בסיסיים – מזהה ייחודי, כתובת אימייל ראשית, שם וכתובת URL של תמונה – שמאוחסנים במסד הנתונים של המשתמשים בפרויקט, ושהמשתמש יכול לעדכן (iOS, Android, אינטרנט). אי אפשר להוסיף מאפיינים אחרים לאובייקט המשתמש ישירות. במקום זאת, אפשר לאחסן את המאפיינים הנוספים בכל שירות אחסון אחר, כמו Google Cloud Firestore.
בפעם הראשונה שמשתמש נרשם לאפליקציה, נתוני הפרופיל שלו מאוכלסים באמצעות המידע שזמין:
- אם המשתמש נרשם באמצעות כתובת אימייל וסיסמה, רק המאפיין של כתובת האימייל הראשית מאוכלס
- אם המשתמש נרשם באמצעות ספק זהויות מאוחד, כמו Google או פייסבוק, פרטי החשבון שזמינים דרך הספק משמשים לאכלוס הפרופיל של המשתמש.
- אם המשתמש נרשם באמצעות מערכת האימות המותאמת אישית שלכם, אתם צריכים להוסיף באופן מפורש את המידע שאתם רוצים לפרופיל המשתמש.
אחרי שיוצרים חשבון משתמש, אפשר לטעון מחדש את פרטי המשתמש כדי לשלב שינויים שהמשתמש ביצע במכשיר אחר.
ספקי כניסה
יש כמה שיטות שבהן אפשר להשתמש כדי לאפשר למשתמשים להיכנס לאפליקציות שלכם: כתובת אימייל וסיסמה, ספקי זהויות מאוחדים ומערכת אימות מותאמת אישית. אפשר לשייך למשתמש יותר משיטת כניסה אחת: לדוגמה, משתמש יכול להיכנס לאותו חשבון באמצעות כתובת אימייל וסיסמה, או באמצעות כניסה לחשבון Google.
במופעים של משתמשים מתבצע מעקב אחרי כל ספק שמקושר למשתמש. כך תוכלו לעדכן את המאפיינים של פרופיל ריק באמצעות המידע שסופק על ידי פלאגין שמתממשק עם שירותים חיצוניים. מידע נוסף זמין במאמר בנושא ניהול משתמשים (iOS, Android, אינטרנט).
המשתמש הנוכחי
כשמשתמש נרשם או נכנס לחשבון, הוא הופך למשתמש הנוכחי של מופע האימות. המופע שומר את מצב המשתמש, כך שרענון הדף (בדפדפן) או הפעלה מחדש של האפליקציה לא יגרמו לאובדן המידע של המשתמש.
כשהמשתמש יוצא מהחשבון, מופסקת ההפניה של מופע האימות לאובייקט המשתמש, והמצב שלו לא נשמר יותר. אין משתמש נוכחי. עם זאת, מופע המשתמש ממשיך להיות פונקציונלי לחלוטין: אם שומרים הפניה אליו, עדיין אפשר לגשת לנתוני המשתמש ולעדכן אותם.
מחזור החיים של המשתמש
הדרך המומלצת לעקוב אחרי המצב הנוכחי של מופע האימות היא באמצעות listeners (נקראים גם observers ב-JavaScript). המאזין לאימות מקבל הודעה בכל פעם שקורה משהו רלוונטי לאובייקט האימות. מידע נוסף זמין במאמר בנושא ניהול משתמשים (iOS, Android, אינטרנט).
מאזין אימות מקבל התראה במצבים הבאים:
- אובייקט האימות מסיים את האתחול ומשתמש כבר מחובר מסשן קודם, או שהופנה מחדש מתהליך הכניסה של ספק הזהויות
- משתמש מתחבר לחשבון (המשתמש הנוכחי מוגדר)
- משתמש יוצא מהחשבון (המשתמש הנוכחי הופך ל-null)
- טוקן הגישה של המשתמש הנוכחי מתרענן. המצב הזה יכול לקרות בתנאים הבאים:
- התוקף של טוקן הגישה פג: זה מצב נפוץ. אסימון הרענון משמש לקבלת קבוצה חדשה של אסימונים תקפים.
- המשתמש משנה את הסיסמה: מערכת Identity Platform מנפיקה טוקנים חדשים של גישה ורענון, והטוקנים הישנים הופכים ללא תקפים. הפעולה הזו גורמת לפקיעת התוקף של הטוקן של המשתמש באופן אוטומטי, או להתנתקות של המשתמש מכל מכשיר, מטעמי אבטחה.
- המשתמש מאמת מחדש את הזהות שלו: חלק מהפעולות דורשות שהאישורים של המשתמש יונפקו לאחרונה. הפעולות האלה כוללות מחיקת חשבון, הגדרת כתובת אימייל ראשית ושינוי סיסמה. במקום לנתק את המשתמש ואז לחבר אותו שוב, צריך לקבל מהמשתמש פרטי כניסה חדשים ולהעביר אותם לשיטת האימות מחדש של אובייקט המשתמש.
שירות עצמי למשתמשים
כברירת מחדל, ב-Identity Platform המשתמשים יכולים להירשם ולמחוק את החשבונות שלהם בלי התערבות של אדמין. במקרים רבים, זה מאפשר למשתמשי קצה לגלות את האפליקציה או השירות שלכם ולהצטרף (או לבטל את ההצטרפות) בקלות.
עם זאת, יש מצבים שבהם רוצים שאדמין ייצור משתמשים באופן ידני או באופן פרוגרמטי, באמצעות SDK לאדמינים אוGoogle Cloud מסוף. במקרים כאלה, אפשר להשבית את פעולות המשתמשים בדף ההגדרות של Identity Platform, וכך למנוע ממשתמשי קצה ליצור ולמחוק חשבונות. אם אתם משתמשים בגישה מרובת דיירים, אתם צריכים לשלוח בקשת HTTP כדי להשבית את התכונות האלה לכל דייר בנפרד.
אם משתמש קצה מנסה ליצור או למחוק חשבון במערכת שלכם, שירות Identity Platform יחזיר קוד שגיאה: auth/admin-restricted-operation לקריאות ל-Web API, או ERROR_ADMIN_RESTRICTED_OPERATION ל-Android ול-iOS. צריך לטפל בשגיאה בצורה אלגנטית בחלק הקדמי של האתר, ולבקש מהמשתמש לבצע את הפעולות המתאימות בשירות שלכם.
טוקנים לאימות
כשמבצעים אימות באמצעות Identity Platform, יכולים להיות שלושה סוגים של טוקנים לאימות:
| אסימונים מזהים ב-Identity Platform | נוצרים על ידי Identity Platform כשמשתמש נכנס לאפליקציה. האסימונים האלה הם אסימוני JWT חתומים שמזהים משתמש בפרויקט Google Cloudבצורה מאובטחת. האסימונים האלה מכילים מידע בסיסי על הפרופיל של המשתמש, כולל מחרוזת המזהה של המשתמש, שהיא ייחודית ל Google Cloudהפרויקט. אפשר לאמת את השלמות של אסימוני הזהות, ולכן אפשר לשלוח אותם לשרת קצה עורפי כדי לזהות את המשתמש שמחובר כרגע. |
| אסימונים של ספק הזהויות | נוצרות על ידי ספקי זהויות מאוחדים, כמו Google ו-Facebook. האסימונים האלה יכולים להיות בפורמטים שונים, אבל לרוב הם אסימוני גישה מסוג OAuth 2.0. האפליקציות משתמשות באסימונים האלה כדי לוודא שהמשתמשים עברו אימות בהצלחה אצל ספק הזהויות, ואז ממירות אותם לפרטי כניסה שאפשר להשתמש בהם בשירותי Identity Platform. |
| טוקנים בהתאמה אישית ב-Identity Platform | נוצר על ידי מערכת האימות המותאמת אישית כדי לאפשר למשתמשים להיכנס לאפליקציה באמצעות מערכת האימות שלכם. אסימונים בהתאמה אישית הם אסימוני JWT שנחתמים באמצעות המפתח הפרטי של חשבון שירות. האפליקציות משתמשות באסימונים האלה בדומה לאסימונים שמוחזרים מספקי זהויות מאוחדים. |
כתובות אימייל מאומתות
מערכת Identity Platform מחשיבה כתובת אימייל כמאומתת אם היא עומדת בשני תנאים:
- המשתמש משלים את תהליך האימות ב-Identity Platform
- האימייל מאומת על ידי ספק זהויות מהימן, או IdP בקיצור.
ספקי זהויות שמאמתים את כתובת האימייל פעם אחת, אבל מאפשרים למשתמשים לשנות את כתובות האימייל בלי לדרוש אימות מחדש, לא נחשבים מהימנים. ספקי זהויות שהם הבעלים של הדומיין או שתמיד דורשים אימות נחשבים מהימנים.
ספקים מהימנים:
- Google (לכתובות שמסתיימות ב- @gmail.com)
- Yahoo (לכתובות עם הסיומת @yahoo.com)
- מיקרוסופט (לכתובות בפורמט @outlook.com ו- @hotmail.com)
- אפל (תמיד מאומת, כי החשבונות תמיד מאומתים ומוגדר בהם אימות רב-שלבי)
ספקים לא מהימנים:
- GitHub
- Google, Yahoo ו-Microsoft לדומיינים שלא הונפקו על ידי ספק הזהויות הזה
- כתובת אימייל / סיסמה ללא אימות כתובת האימייל
במצבים מסוימים, מערכת Identity Platform תקשר אוטומטית בין חשבונות כשמשתמש נכנס לחשבון עם ספקים שונים באמצעות אותה כתובת אימייל. עם זאת, זה יכול לקרות רק אם מתקיימים קריטריונים ספציפיים. כדי להבין למה, נסתכל על המקרה הבא: משתמש מתחבר באמצעות חשבון Google עם כתובת @gmail.com, וגורם זדוני יוצר חשבון באמצעות אותה כתובת @gmail.com, אבל מתחבר דרך פייסבוק. אם שני החשבונות האלה קושרו אוטומטית, הגורם הזדוני יקבל גישה לחשבון של המשתמש.
במקרים הבאים מתואר מתי אנחנו מקשרים חשבונות באופן אוטומטי ומתי אנחנו מציגים שגיאה שדורשת פעולה מצד המשתמש או המפתח:
- משתמש נכנס לחשבון באמצעות ספק לא מהימן, ואז נכנס לחשבון באמצעות ספק לא מהימן אחר עם אותה כתובת אימייל (לדוגמה, פייסבוק ואז GitHub). במקרה כזה, תוצג שגיאה שדורשת קישור חשבון.
- משתמש נכנס לחשבון באמצעות ספק מהימן, ואז נכנס לחשבון באמצעות ספק לא מהימן עם אותה כתובת אימייל (לדוגמה, Google ואז פייסבוק). במקרה כזה, תוצג שגיאה שדורשת קישור חשבון.
- המשתמש נכנס באמצעות ספק לא מהימן, ואז נכנס באמצעות ספק מהימן עם אותה כתובת אימייל (לדוגמה, פייסבוק ואז Google). הספק המהימן מחליף את הספק הלא מהימן. אם המשתמש ינסה להיכנס שוב באמצעות פייסבוק, תוצג שגיאה שתדרוש קישור חשבונות.
- משתמש נכנס באמצעות ספק מהימן, ואז נכנס באמצעות ספק מהימן אחר עם אותה כתובת אימייל (לדוגמה, Apple ואז Google). שני הספקים יקושרו ללא שגיאות.
אפשר להגדיר אימייל כמאומת באופן ידני באמצעות SDK לאדמינים, אבל מומלץ לעשות זאת רק אם אתם יודעים שהמשתמש הוא הבעלים של כתובת האימייל.