מעבר מערכת הכלים של Google Identity לפלטפורמת Identity Platform של Google Cloud

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

תכונות חדשות

ל-Identity Platform כבר יש שיפורים משמעותיים בתכונות בהשוואה ל-Google Identity Toolkit:

  • מסוף Admin חדש

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

  • שיטות אימות חדשות

    פלטפורמת Identity Platform תומכת בתקני איחוד ארגוניים, כמו SAML ו-OIDC, ומאפשרת לכם להרחיב את השימוש באפליקציות ובשירותי SaaS. פלטפורמת Identity Platform תומכת גם בספקים כמו GitHub, ‏ Microsoft, ‏ Yahoo ועוד. אתם יכולים להשתמש בכניסה אנונימית כדי ליצור מזהה משתמש ייחודי בלי שהמשתמש יצטרך לעבור תהליך כניסה או הרשמה. כך תוכלו לבצע קריאות מאומתות ל-API כמו במקרה של משתמש רגיל. כשהמשתמש מחליט להירשם לחשבון, כל הפעילות נשמרת עם אותו User-ID. התכונה הזו שימושית בתרחישים כמו עגלות קניות בצד השרת או אפליקציות אחרות שבהן רוצים לעודד את המשתמשים להירשם לפני ששולחים אותם לתהליך הרשמה.

  • התרחבות בביטחון בעזרת הסכמי רמת שירות ותמיכה בענן

    ‫Identity Platform מבוסס על תשתית מהימנה של Google, ומספק הסכמי רמת שירות (SLA) ותמיכה מ-Google Cloud. המשמעות היא שאתם יכולים להרחיב את השירות שלכם בביטחון, ולהסתמך על Google שתספק את העמידות, הזמינות והמדרגיות שאתם צריכים.

  • גישה לכל התכונות של Firebase

    ‫Firebase היא פלטפורמה לניידים שעוזרת לכם לפתח במהירות אפליקציות באיכות גבוהה, להגדיל את בסיס המשתמשים ולהרוויח יותר כסף. ‫Firebase מורכב מתכונות משלימות שאפשר לשלב ביניהן כדי להתאים לצרכים שלכם, והוא כולל תשתית ל:Analytics לנייד, העברת הודעות בענן, מסד נתונים בזמן אמת, אחסון קבצים, אירוח סטטי, הגדרת תצורה מרחוק, דיווח על קריסות בנייד ובדיקות ב-Android.

  • ממשקי משתמש מעודכנים

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

  • הגדרה פשוטה יותר של השרת

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

  • ערכות SDK חדשות

    כל ממשקי ה-API של השרת של Identity Toolkit זמינים עכשיו באופן מקורי בכל אחת מספריות הלקוח שלנו (Android, ‏ iOS, ‏ web). מפתחים יוכלו להיכנס ולרשום משתמשים חדשים וישנים, לגשת למאפייני משתמשים, לקשר, לעדכן ולמחוק חשבונות, לאפס סיסמאות ועוד, בלי להיות קשורים לממשק משתמש קבוע. אם אתם מעדיפים, אתם יכולים ליצור באופן ידני תהליך כניסה מלא משלכם על בסיס ה-API הזה.

  • ניהול סשנים באפליקציות לנייד

    באמצעות Identity Toolkit, האפליקציות יצרו מצב סשן משלהן על סמך אירוע האימות הראשוני מ-Identity Toolkit. ב-Identity Platform נעשה שימוש בשירות לקצה העורפי שמקבל אסימון רענון שנוצר מאירוע האימות, ומחליף אותו באסימוני גישה למשך שעה ל-Android, ל-iOS ול-JavaScript. כשמשתמש משנה את הסיסמה שלו, אסימוני הרענון לא יכולים יותר ליצור אסימוני גישה חדשים, ולכן הגישה מושבתת עד שהמשתמש מבצע אימות מחדש במכשיר הזה.

הבדלים בתכונות

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

הבדלים בצד השרת

שירות הליבה של Identity Toolkit, עם ממשקי ה-REST API הבסיסיים שלו, לוגיקת אימות החשבון ומסד הנתונים הראשי של המשתמשים, עבר רק עדכונים קלים. אבל חלק מהתכונות והאופן שבו משלבים את Identity Platform בשירות השתנו.

  • ספקי זהויות

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

  • ספריות שרת

    נכון לעכשיו, יש Admin SDKs זמינים ל-Java, ל-Node.js, ל-Python, ל-Go ול-C#.

  • אימיילים לניהול החשבון

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

  • אישור שינוי כתובת האימייל

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

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

  • השקת IDP

    ב-Identity Toolkit הייתה אפשרות להוסיף ספקי זהויות למערכת הכניסה שלכם בהדרגה, כדי שתוכלו לבדוק את ההשפעה על בקשות התמיכה שלכם. התכונה הזו הוסרה מאימות ב-Firebase.

הבדלים בצד הלקוח

ב-Identity Platform, התכונות שמסופקות על ידי Google Identity Toolkit מחולקות לשני רכיבים:

  • ערכות SDK ללקוח ולשרת

    ב-Identity Platform, הפונקציונליות שמסופקת על ידי ה-API בארכיטקטורת REST של Identity Toolkit ארוזה ב-SDK ללקוח שזמין ל-Android, ל-iOS ול-JavaScript. אתם יכולים להשתמש ב-SDK כדי לאפשר למשתמשים להיכנס ולרשום חשבונות, לגשת לפרטי הפרופיל של המשתמשים, לקשר, לעדכן ולמחוק חשבונות ולאפס סיסמאות באמצעות ה-SDK של הלקוח, במקום לתקשר עם שירות ה-Back End באמצעות קריאות REST.

  • UI Widget

    כל תהליכי המשתמש שמנהלים כניסה, הרשמה, שחזור סיסמה וקישור חשבון נבנו מחדש באמצעות ערכות ה-SDK של הלקוח ונארזו כווידג'ט כניסה. הם זמינים כערכות SDK בקוד פתוח ל-iOS, ל-Android ול-Web, ומאפשרים לכם להתאים אישית את התהליכים בצורה שלא אפשרית באמצעות Identity Toolkit.

הבדלים נוספים:

  • סשנים והעברה

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

לפני שמתחילים

כדי לעבור מ-Identity Toolkit ל-Identity Platform, אתם צריכים:

  1. פותחים את מסוף Cloud ובוחרים את הפרויקט של Identity Toolkit.

  2. ב-Marketplace, עוברים אל Identity Platform ובוחרים באפשרות 'הפעלת Identity Platform'.

  3. פותחים את הדף חשבונות שירות. כאן אפשר לראות את חשבון השירות שהגדרתם בעבר עבור Identity Toolkit.

  4. לצד חשבון השירות, לוחצים על > יצירת מפתח. לאחר מכן, בתיבת הדו-שיח Create private key (יצירת מפתח פרטי), מגדירים את סוג המפתח ל-JSON ולוחצים על Create (יצירה). קובץ JSON שמכיל את פרטי הכניסה של חשבון השירות יורד למחשב. תצטרכו את המזהה הזה כדי להפעיל את ה-SDK בשלב הבא.

  5. חוזרים אל מסוף Cloud. בקטע Providers (ספקים), בשיטת הכניסה Email/Password (אימייל/סיסמה), פותחים את הדף Email Templates (תבניות אימייל). אחר כך תוכלו להתאים אישית את התבניות של האפליקציה.

    ב-Identity Toolkit, כשמשתמשים מאפסים סיסמאות, משנים כתובות אימייל או מאמתים את כתובות האימייל שלהם, צריך לקבל קוד OOB משרת Identity Toolkit ואז לשלוח את הקוד למשתמשים באימייל. מערכת Identity Platform שולחת אימיילים על סמך התבניות שהגדרתם, בלי שנדרשות פעולות נוספות.

  6. אופציונלי: אם אתם צריכים לגשת לשירותי Identity Platform בשרת שלכם, אתם צריכים להתקין את Firebase SDK.

    1. אפשר להתקין את Node.js SDK לאדמינים באמצעות npm:

      $ npm init
$ npm install --save firebase-admin

    2. בקוד, אפשר לגשת ל-Firebase באמצעות:

      var admin = require('firebase-admin');
var app = admin.initializeApp({
  credential: admin.credential.cert('path/to/serviceAccountCredentials.json')
});

בשלב הבא, משלימים את שלבי ההעברה לפלטפורמה של האפליקציה: Android,‏ iOS, ‏ web.

שרתים ו-JavaScript

שינויים בולטים

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

  • ניהול סשנים באינטרנט

    בעבר, כשמשתמש עבר אימות באמצעות הווידג' של Identity Toolkit, הוגדר קובץ Cookie למשתמש, ששימש לאתחול הסשן. תוקף קובץ ה-Cookie הזה היה שבועיים, והוא שימש כדי לאפשר למשתמש להשתמש בווידג'ט לניהול החשבון כדי לשנות את הסיסמה ואת כתובת האימייל. חלק מהאתרים השתמשו בקובץ ה-Cookie הזה כדי לאמת את כל בקשות הדפים האחרות באתר. אתרים אחרים השתמשו בקובץ ה-Cookie כדי ליצור קובצי Cookie משלהם באמצעות מערכת ניהול קובצי ה-Cookie של המסגרת שלהם.

    ערכות ה-SDK של הלקוח של Identity Platform מנהלות עכשיו אסימוני זהות ועובדות עם הקצה העורפי של Identity Platform כדי לשמור על עדכניות הסשן. המערכת העורפית מסיימת את הפעילות של סשנים כשמתבצעים שינויים חשובים בחשבון (כמו שינויים בסיסמה של משתמש). אסימוני מזהה לא מוגדרים אוטומטית כקובצי Cookie בלקוח האינטרנט, והם תקפים רק לשעה אחת. אלא אם אתם רוצים סשנים של שעה אחת בלבד, לא מומלץ להשתמש בטוקנים של מזהי סשן כקובץ Cookie לאימות כל הבקשות שלכם לדפים. במקום זאת, תצטרכו להגדיר מאזין למצב שבו המשתמש מתחבר, לקבל את אסימון הזהות, לאמת את האסימון וליצור קובץ Cookie משלכם באמצעות מערכת ניהול קובצי ה-Cookie של המסגרת.

    תצטרכו להגדיר את משך החיים של קובץ ה-Cookie בהתאם לצרכי האבטחה של האפליקציה.

  • תהליך הכניסה לאתר

    בעבר, המשתמשים הופנו אל accountchooser.com כשהם התחילו להיכנס לחשבון, כדי לדעת באיזה מזהה הם רוצים להשתמש. התהליך בממשק המשתמש של Identity Platform מתחיל עכשיו עם רשימה של שיטות כניסה, כולל אפשרות כניסה באמצעות אימייל שמובילה אל accountchooser.com לאינטרנט ומשתמשת ב-hintRequest API ב-Android. בנוסף, כבר לא נדרשות כתובות אימייל בממשק המשתמש. כך יהיה קל יותר לתמוך במשתמשים אנונימיים, במשתמשים עם אימות מותאם אישית או במשתמשים מספקים שלא נדרשות בהם כתובות אימייל.

  • ווידג'ט של ניהול החשבון

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

  • לחצן או ווידג'ט לכניסה

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

  • No signOutUrl

    תצטרכו להתקשר למספר firebase.auth.signOut() ולטפל בשיחה החוזרת.

  • No oobActionUrl

    הטיפול בשליחת אימיילים מתבצע עכשיו על ידי Identity Platform, וההגדרה מתבצעת במסוף Firebase.

  • התאמה אישית של CSS

    ווידג'ט ממשק המשתמש משתמש בעיצוב Material Design Lite, שמוסיף אנימציות של Material Design באופן דינמי.

שלב 1: שינוי קוד השרת

  1. אם השרת שלכם מסתמך על טוקן של Identity Toolkit (תקף לשבועיים) כדי לנהל סשנים של משתמשי אינטרנט, אתם צריכים להמיר את השרת לשימוש בקובץ Cookie זמני משלו של סשן.

    1. מטמיעים נקודת קצה לאימות של טוקן הזהות ולהגדרת קובץ ה-Cookie הזמני של הסשן עבור המשתמש. אפליקציית הלקוח שולחת את אסימון המזהה ב-Firebase לנקודת הקצה הזו.
    2. אם הבקשה הנכנסת מכילה את קובץ ה-Cookie הזמני שלכם, אפשר להניח שהמשתמש מאומת. אחרת, יש להתייחס לבקשה כאל בקשה לא מאומתת.
    3. אם אתם לא רוצים שאף אחד מהמשתמשים שלכם יאבד את הסשנים הקיימים שלו, אתם צריכים לחכות שבועיים עד שכל האסימונים של Identity Toolkit יפוגו, או לבצע גם את אימות האסימונים הכפול עבור אפליקציית האינטרנט שלכם, כפי שמתואר בשלב 3 בהמשך.

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

  3. כשמבצעים את העדכונים שלמעלה בפעם הראשונה, יכול להיות שעדיין יהיו נתיבי קוד שמסתמכים על אסימונים של Identity Toolkit. אם יש לכם אפליקציות ל-iOS או ל-Android, המשתמשים יצטרכו לשדרג לגרסה החדשה של האפליקציה כדי שנתיבי הקוד החדשים יפעלו. אם אתם לא רוצים לחייב את המשתמשים לעדכן את האפליקציה, אתם יכולים להוסיף לוגיקה נוספת לאימות השרת, שתבדוק את האסימון ותקבע אם צריך להשתמש ב-Firebase SDK או ב-Identity Toolkit SDK כדי לאמת את האסימון. אם יש לכם רק אפליקציית אינטרנט, כל בקשות האימות החדשות יועברו אל Identity Platform, ולכן תצטרכו להשתמש רק בשיטות האימות של אסימון הזהות.

מידע נוסף זמין במאמר בנושא הפניית Web API.

שלב 2: מעדכנים את ה-HTML

  1. מוסיפים את קוד האתחול לאפליקציה:

    1. פותחים את הפרויקט במסוף Cloud.
    2. בדף ספקים, לוחצים על פרטי הגדרת האפליקציה. מוצג קטע קוד שמבצע אתחול של Identity Platform.
    3. מעתיקים את קטע הקוד של ההפעלה ומדביקים אותו בדף האינטרנט.

  2. מוסיפים את ווידג'ט האימות לאפליקציה:

    <script src="https://www.gstatic.com/firebasejs/ui/live/0.4/firebase-ui-auth.js"></script>
<link type="text/css" rel="stylesheet" href="https://www.gstatic.com/firebasejs/ui/live/0.4/firebase-ui-auth.css" />
<!-- *******************************************************************************************
   * TODO(DEVELOPER): Paste the initialization snippet from:
   * Firebase Console > Overview > Add Firebase to your web app. *
   ***************************************************************************************** -->
<script type="text/javascript">
  // FirebaseUI config.
  var uiConfig = {
    'signInSuccessUrl': '<url-to-redirect-to-on-success>',
    'signInOptions': [
      // Leave the lines as is for the providers you want to offer your users.
      firebase.auth.GoogleAuthProvider.PROVIDER_ID,
      firebase.auth.FacebookAuthProvider.PROVIDER_ID,
      firebase.auth.TwitterAuthProvider.PROVIDER_ID,
      firebase.auth.GithubAuthProvider.PROVIDER_ID,
      firebase.auth.EmailAuthProvider.PROVIDER_ID
    ],
    // Terms of service url.
    'tosUrl': '<your-tos-url>',
  };

  // Initialize the FirebaseUI Widget using Firebase.
  var ui = new firebaseui.auth.AuthUI(firebase.auth());
  // The start method will wait until the DOM is loaded.
  ui.start('#firebaseui-auth-container', uiConfig);
</script>

  3. מסירים את Identity Toolkit SDK מהאפליקציה.

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

    1. אחרי שנכנסים בהצלחה באמצעות Identity Platform, מקבלים אסימון מזהה על ידי קריאה ל-firebase.auth().currentUser.getToken().

    2. שולחים את טוקן ה-ID לשרת הבק-אנד, מאמתים אותו ומנפיקים קובץ Cookie זמני משלכם לסשן.

      אל תסתמכו רק על קובץ Cookie זמני כשמבצעים פעולות רגישות או כששולחים לשרת בקשות עריכה מאומתות. תצטרכו לספק הגנה נוספת מפני זיוף בקשות בין אתרים (CSRF).

      אם הפלטפורמה שלכם לא מספקת הגנה מפני CSRF, אחת הדרכים למנוע מתקפה היא לקבל אסימון מזהה עבור המשתמש המחובר באמצעות getToken() ולכלול את האסימון בכל בקשה (קובץ ה-cookie של הסשן יישלח גם הוא כברירת מחדל). לאחר מכן תאמתו את האסימון באמצעות SDK לאדמינים בנוסף לבדיקת קובץ Cookie זמני, שהושלמה על ידי מסגרת ה-Backend שלכם. כך יהיה קשה יותר להצליח במתקפות CSRF, כי אסימון ה-ID מאוחסן רק באמצעות אחסון אינטרנטי ולא בקובץ Cookie.

    3. האסימונים של Identity Toolkit תקפים למשך שבועיים. אפשר להמשיך להנפיק טוקנים שתוקפם הוא שבועיים, או להאריך או לקצר את התוקף בהתאם לדרישות האבטחה של האפליקציה. כשמשתמש מתנתק, צריך לנקות את קובץ ה-Cookie הזמני.

שלב 3: מעדכנים את כתובות ה-URL של ההפניות האוטומטיות של ספק הזהויות

  1. במסוף Cloud, פותחים את הקטע Providers.

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

    1. לוחצים על השם של ספק הכניסה.
    2. מעתיקים את ה-URI של ההפניה האוטומטית ב-OAuth.
    3. ב-Developer Console של ספק הכניסה, מעדכנים את ה-URI של ההפניה האוטומטית של OAuth.

Android

שלב 1: מוסיפים את Identity Platform לאפליקציה באמצעות Firebase

  1. פותחים את Cloud Console ובוחרים את הפרויקט של Identity Toolkit.

  2. בדף 'ספקים', לוחצים על פרטי הגדרת האפליקציה, בוחרים בכרטיסייה Android ואז לוחצים על שנתחיל ב-Firebase. בתיבת הדו-שיח Add Firebase (הוספת Firebase), מזינים את שם החבילה של האפליקציה ואת טביעת האצבע לאישור החתימה, ולוחצים על Add App (הוספת אפליקציה). קובץ ההגדרות google-services.json יורד למחשב.

  3. מעתיקים את קובץ ההגדרות לתיקיית השורש של מודול האפליקציה ל-Android. קובץ ההגדרה הזה מכיל מידע על הפרויקט ועל לקוח Google OAuth.

  4. בקובץ build.gradle ברמת הפרויקט (<var>your-project</var>/build.gradle), מציינים את שם החבילה של האפליקציה בקטע defaultConfig:

    defaultConfig {
   …..
  applicationId "com.your-app"
}

  5. בנוסף, בקובץ build.gradle ברמת הפרויקט, מוסיפים תלות כדי לכלול את הפלאגין google-services:

    buildscript {
 dependencies {
   // Add this line
   classpath 'com.google.gms:google-services:3.0.0'
 }
}

  6. בקובץ build.gradle ברמת האפליקציה<var>my-project</var>/<var>app-module</var>/build.gradle, מוסיפים את השורה הבאה אחרי פלאגין של Android Gradle כדי להפעיל את הפלאגין google-services:

    apply plugin: 'com.android.application'
// Add this line
apply plugin: 'com.google.gms.google-services'

    התוסף google-services משתמש בקובץ google-services.json כדי להגדיר את האפליקציה לשימוש ב-Firebase.

  7. בנוסף, בקובץ build.gradle ברמת האפליקציה, מוסיפים את התלות ב-Firebase Authentication:

    compile 'com.google.firebase:firebase-auth:24.1.0'
compile 'com.google.android.gms:play-services-auth:21.6.0'

שלב 2: מסירים את Identity Toolkit SDK

  1. מסירים את ההגדרה של Identity Toolkit מהקובץ AndroidManifest.xml. המידע הזה נכלל בקובץ google-service.json והוא נטען על ידי התוסף google-services.
  2. מסירים את Identity Toolkit SDK מהאפליקציה.

שלב 3: הוספת FirebaseUI לאפליקציה

  1. מוסיפים את FirebaseUI Auth לאפליקציה.

  2. באפליקציה, מחליפים את הקריאות ל-Identity Toolkit SDK בקריאות ל-FirebaseUI.

iOS

שלב 1: מוסיפים את Firebase לאפליקציה

  1. מריצים את הפקודות הבאות כדי להוסיף את ה-SDK של הלקוח לאפליקציה:

    $ cd your-project directory
$ pod init
$ pod 'Firebase'

  2. פותחים את Cloud Console ובוחרים את הפרויקט של Identity Toolkit.

  3. בדף 'ספקי זהויות', לוחצים על פרטי הגדרת האפליקציה, בוחרים בכרטיסייה iOS ואז לוחצים על תחילת העבודה ב-Firebase. בתיבת הדו-שיח 'הוספת Firebase', מזינים את שם החבילה של האפליקציה ואת טביעת האצבע לאישור החתימה ולוחצים על הוספת אפליקציה. קובץ ההגדרות google-services.json יורד למחשב. בתיבת הדו-שיח Add Firebase (הוספת Firebase), מזינים את מזהה החבילה ואת המזהה של App Store של האפליקציה, ואז לוחצים על Add App (הוספת אפליקציה). קובץ ההגדרה GoogleService-Info.plist יורד למחשב. אם יש לכם כמה מזהי חבילות בפרויקט, צריך לקשר כל מזהה חבילה במסוף Firebase כדי שיהיה לו קובץ GoogleService-Info.plist משלו.

  4. מעתיקים את קובץ ההגדרות לתיקיית השורש של פרויקט Xcode ומוסיפים אותו לכל היעדים.

שלב 2: מסירים את Identity Toolkit SDK

  1. מסירים את GoogleIdentityToolkit מהקובץ Podfile של האפליקציה.
  2. מריצים את הפקודה pod install.

שלב 3: הוספת FirebaseUI לאפליקציה

  1. מוסיפים את FirebaseUI Auth לאפליקציה.

  2. באפליקציה, מחליפים את הקריאות ל-Identity Toolkit SDK בקריאות ל-FirebaseUI.