יישם ספק בדיקת אפליקציות מותאם אישית

בדקו שאפליקצית תמיכה מובנית עבור מספר ספקים: DeviceCheck ו App מעיד על פלטפורמות אפלות, SafetyNet על אנדרואיד, או v3 reCAPTCHA באפליקציות אינטרנט ( סקירה ). אלו הם ספקים מובנים שצריכים לענות על הצרכים של רוב המפתחים. עם זאת, אתה יכול גם ליישם ספקי App Check מותאמים אישית משלך. שימוש בספק מותאם אישית הכרחי כאשר:

  • אתה רוצה להשתמש בספק אחר מלבד DeviceCheck או App Attest ב-Apple, SafetyNet ב-Android או reCAPTCHA באפליקציות אינטרנט.

  • אתה רוצה לאמת מכשירים באמצעות פלטפורמות אחרות מלבד אפל, אנדרואיד והאינטרנט. לדוגמה, תוכל ליצור ספקי App Check עבור מערכת הפעלה שולחנית או התקני Internet-of-Things.

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

סקירה כללית

כדי ליישם ספקית בדיקת יישום מותאם אישית, אתה צריך סביבה backend מאובטח שיכול להפעיל את Node.js SDK של ניהול Firebase . זה יכול להיות פונקציות ענן, רציף מכולות כגון ענן הפעלה , או שרת משלך.

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

בדרך כלל, אתה חושף את השירות הזה כנקודת קצה של REST או gRPC, אבל פרט זה תלוי בך.

צור את נקודת הקצה של רכישת האסימון

  1. התקן לאתחל SDK של מנהל המערכת .

  2. צור נקודת קצה נגישה לרשת שיכולה לקבל נתוני אותנטיות מהלקוחות שלך. לדוגמה, שימוש בפונקציות ענן:

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
    exports.fetchAppCheckToken = functions.https.onCall((authenticityData, context) => {
      // ...
    });
    
  3. הוסף לנקודת הקצה היגיון שמעריך את נתוני האותנטיות. זהו ההיגיון הליבה של ספק האפליקציות המותאם אישית שלך, אותו תצטרך לכתוב בעצמך.

  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) לאסימוני בדיקת יישום שהוציאו הספק המותאם אישית על ידי העברת AppCheckTokenOptions מתנגד createToken() . אתה יכול להגדיר את ה-TTL לכל ערך בין 30 דקות ל-7 ימים. בעת הגדרת ערך זה, שים לב להחלפות הבאות:

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

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

הצעדים הבאים

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