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

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

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

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

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

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

סקירה כללית

כדי להטמיע ספק App Check בהתאמה אישית, נדרשת סביבת קצה עורפי מאובטחת שיכולה להריץ את Node.js Firebase Admin SDK. יכול להיות שזה יהיה 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 ואינטרנט.