שימוש ב-App Check כדי לאבטח את מפתח ה-API

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

האם App Check מתאים לי?

ברוב המקרים מומלץ להשתמש ב-App Check, אבל אין צורך ב-App Check או שהוא לא נתמך במקרים הבאים:

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

סקירה כללית של שלבי ההטמעה

באופן כללי, אלה השלבים שצריך לבצע כדי לשלב את האפליקציה עם App Check:

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

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

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

שיקולים בתכנון שילוב של App Check

כמה דברים שכדאי לקחת בחשבון כשמתכננים את השילוב:

לספק האישורים המומלץ שלנו, Play Integrity, יש מגבלה יומית על מספר הקריאות לרמת השימוש הרגילה ב-API. מידע נוסף על מגבלות קריאות זמין בדף הגדרה במסמכי התיעוד למפתחים של Google Play Integrity.

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

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

שילוב האפליקציה עם App Check

דרישות מוקדמות

אפליקציה שמשולבת בה גרסה 4.1 ואילך של Places SDK.
טביעת האצבע מסוג SHA-256 של האפליקציה.
שם החבילה של האפליקציה.
אתם צריכים להיות הבעלים של האפליקציה ב-Cloud Console.
תצטרכו את מזהה הפרויקט של האפליקציה מ-Cloud Console.

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

פועלים לפי ההוראות במסמכי התיעוד למפתחים של Firebase כדי להוסיף את Firebase לאפליקציה.

שלב 2: מוסיפים את ספריית App Check ומפעילים את App Check

מידע על השימוש ב-Play Integrity, ספק האימות שמוגדר כברירת מחדל, זמין במאמר תחילת השימוש ב-App Check עם Play Integrity ב-Android.

אם עדיין לא עשיתם זאת, משלבים את Places SDK באפליקציה.

לאחר מכן, מאתחלים את App Check ואת הלקוח של Places.

// Initialize App Check
FirebaseApp.initializeApp(/* context= */ this);
FirebaseAppCheck firebaseAppCheck = FirebaseAppCheck.getInstance();
firebaseAppCheck.installAppCheckProviderFactory(
        PlayIntegrityAppCheckProviderFactory.getInstance());
  
// Initialize Places SDK
Places.initializeWithNewPlacesApiEnabled(context, API_KEY);
PlacesClient client = Places.createClient(context);.

שלב 3: מוסיפים את ספק האסימונים

אחרי הפעלת Places API, קוראים ל-setPlacesAppCheckTokenProvider() כדי להגדיר את PlacesAppCheckTokenProvider.

Places.initializeWithNewPlacesApiEnabled(context, API_KEY);
Places.setPlacesAppCheckTokenProvider(new TokenProvider());
PlacesClient client = Places.createClient(context);.

הנה דוגמה להטמעה של הממשק להבאת טוקנים:

  /** Sample client implementation of App Check token fetcher interface. */
  static class TokenProvider implements PlacesAppCheckTokenProvider {
    @Override
    public ListenableFuture<String> fetchAppCheckToken() {
      SettableFuture<String> future = SettableFuture.create();
      FirebaseAppCheck.getInstance()
          .getAppCheckToken(false)
          .addOnSuccessListener(
              appCheckToken -> {
                future.set(appCheckToken.getToken());
              })
          .addOnFailureListener(
              ex -> {
                future.setException(ex);
              });

      return future;
    }
  }

שלב 4: הפעלת ניפוי באגים (אופציונלי)

אם אתם רוצים לפתח ולבדוק את האפליקציה באופן מקומי, או להריץ אותה בסביבת שילוב רציף (CI), אתם יכולים ליצור גרסת build לניפוי באגים של האפליקציה שמשתמשת בסוד לניפוי באגים כדי לקבל אסימונים תקפים של App Check. כך תוכלו להימנע משימוש בספקי אימות אמיתיים בגרסת הניפוי שלכם.

כדי להריץ את האפליקציה באמולטור או במכשיר לבדיקה:

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

כדי להריץ את האפליקציה בסביבת CI:

יוצרים אסימון לניפוי באגים במסוף Firebase ומוסיפים אותו למאגר המפתחות המאובטח של מערכת ה-CI.
מוסיפים את ספריית App Check לקובץ build.gradle.
מגדירים את וריאציית ה-build של ה-CI כך שתשתמש באסימון ניפוי הבאגים.
עוטפים את הקוד במחלקות הבדיקה שזקוקות לטוקן של App Check באמצעות DebugAppCheckTestHelper.
מידע נוסף והוראות זמינים במאמרי העזרה בנושא App Check.

שלב 5: מעקב אחרי בקשות האפליקציה והחלטה על אכיפה

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

מידע נוסף והוראות מופיעים במסמכי התיעוד של Firebase App Check.