הטמעת ספק מותאם אישית של App Check

ל-App Check יש תמיכה מובנית בכמה ספקים: DeviceCheck ו-App Attest בפלטפורמות של Apple,‏ Play Integrity ב-Android ו-reCAPTCHA Enterprise באפליקציות אינטרנט (סקירה כללית). אלה ספקים מוכרים שיכולים לענות על הצרכים של רוב המפתחים. עם זאת, אפשר גם להטמיע ספקי App Check מותאמים אישית. צריך להשתמש בספק מותאם אישית במקרים הבאים:

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

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

  • אתם רוצים לאמת מכשירים באמצעות פלטפורמות שאינן Apple,‏ Android והאינטרנט. לדוגמה, אפשר ליצור ספקי App Check למערכות הפעלה למחשבים או למכשירי האינטרנט של הדברים.

  • אתם רוצים להטמיע שיטות אימות משלכם בכל פלטפורמה.

סקירה כללית

כדי להטמיע ספק App Check מותאם אישית, צריך סביבה מאובטחת לקצה העורפי שאפשר להריץ בה את Firebase Admin SDK של Node.js. יכול להיות שזה יהיה Cloud Functions, פלטפורמת קונטיינרים כמו Cloud Run או שרת משלכם.

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

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

יצירת נקודת הקצה לקבלת הטוקן

  1. מתקינים ומפעילים את Admin SDK.

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

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
exports.fetchAppCheckToken = functions.https.onRequest((request, response) => {
  // ...
});

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

  4. אם נקבע שהלקוח הוא אותנטי, משתמשים ב-Admin SDK כדי ליצור טוקן App Check ולהחזיר אותו ללקוח יחד עם מועד התפוגה שלו:

    const admin = require('firebase-admin');
admin.initializeApp();

// ...

admin.appCheck().createToken(appId)
    .then(function (appCheckToken) {
      // Token expires in an hour.
      const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60;

      // Return appCheckToken and expiresAt to the client.
    })
   .catch(function (err) {
     console.error('Unable to create App Check token.');
     console.error(err);
   });

    אם אי אפשר לאמת את האותנטיות של הלקוח, צריך להחזיר שגיאה (לדוגמה, להחזיר שגיאת HTTP 403).

  5. אופציונלי: כדי להגדיר את אורך החיים (TTL) של אסימוני App Check שהנפיק הספק המותאם אישית, מעבירים אובייקט AppCheckTokenOptions אל createToken(). אפשר להגדיר את TTL לכל ערך בין 30 דקות ל-7 ימים. כשמגדירים את הערך הזה, חשוב לשים לב למאזן הפשרות הבא:

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

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

השלבים הבאים

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