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