קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
App Check כולל תמיכה מובנית בכמה ספקים: DeviceCheck ו-App Attest בפלטפורמות של אפל, Play Integrity ב-Android ו-reCAPTCHA Enterprise באפליקציות אינטרנט (סקירה כללית). אלה ספקים מוכרים שצריכים לענות על הצרכים של רוב המפתחים. עם זאת, אפשר גם להטמיע ספקי App Check מותאמים אישית משלכם. צריך להשתמש בספק מותאם אישית במקרים הבאים:
אתם רוצים להשתמש בספק שאינו אחד מהספקים המובנים.
אתם רוצים להשתמש בספקי הזהויות המובנים בדרכים שלא נתמכות.
אתם רוצים לאמת מכשירים באמצעות פלטפורמות אחרות מלבד Apple, Android והאינטרנט. לדוגמה, אפשר ליצור App Check ספקים למערכות הפעלה למחשבים או למכשירי IoT.
אתם רוצים להטמיע טכניקות אימות משלכם בכל פלטפורמה.
סקירה כללית
כדי להטמיע ספק App Check מותאם אישית, צריך סביבת קצה עורפי מאובטחת שיכולה להריץ את Node.js Firebase Admin SDK.
יכול להיות שזה Cloud Functions, פלטפורמת קונטיינרים כמו Cloud Run, או שרת משלכם.
בסביבה הזו, תספקו שירות שנגיש לרשת ומקבל הוכחת מקוריות מלקוחות האפליקציה שלכם. אם הוכחת המקוריות תעבור את הערכת המקוריות שלכם, השירות יחזיר אסימון App Check. האינדיקטורים הספציפיים שבהם תשתמשו כהוכחה לאותנטיות יהיו תלויים בספק הצד השלישי שבו אתם משתמשים, או באינדיקטורים שאתם יוצרים בעצמכם, אם אתם מטמיעים לוגיקה מותאמת אישית.
בדרך כלל חושפים את השירות הזה כנקודת קצה של REST או gRPC, אבל זה תלוי בכם.
יוצרים נקודת קצה (endpoint) שאפשר לגשת אליה ברשת ויכולה לקבל נתוני אותנטיות מהלקוחות. לדוגמה, באמצעות Cloud Functions:
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckTokenexports.fetchAppCheckToken=functions.https.onRequest((request,response)=>{// ...});
מוסיפים ללוגיקה של נקודת הקצה את ההערכה של נתוני האותנטיות. זוהי לוגיקת הליבה של ספק App Check מותאם אישית, שתצטרכו לכתוב בעצמכם.
אם קובעים שהלקוח אותנטי, משתמשים ב-Admin SDK כדי ליצור טוקן App Check ולהחזיר אותו ואת תאריך התפוגה שלו ללקוח:
constadmin=require('firebase-admin');admin.initializeApp();// ...admin.appCheck().createToken(appId).then(function(appCheckToken){// Token expires in an hour.constexpiresAt=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).
אופציונלי: כדי להגדיר את אורך החיים (TTL) של אסימוני App Check שהונפקו על ידי הספק המותאם אישית, מעבירים אובייקט AppCheckTokenOptions אל createToken(). אפשר להגדיר את ה-TTL לכל ערך בין 30 דקות ל-7 ימים. כשמגדירים את הערך הזה, חשוב לשים לב לשיקולים הבאים:
אבטחה: ערכי TTL קצרים יותר מספקים אבטחה חזקה יותר, כי הם מצמצמים את חלון הזמן שבו תוקף יכול לנצל לרעה אסימון שדלף או נחטף.
ביצועים: ערכי TTL קצרים יותר אומרים שהאפליקציה תבצע אימות בתדירות גבוהה יותר. תהליך אימות האפליקציה מוסיף זמן אחזור לבקשות רשת בכל פעם שהוא מתבצע, ולכן ערך TTL קצר יכול להשפיע על ביצועי האפליקציה.
ערך ברירת המחדל של TTL הוא שעה אחת, וזה ערך סביר לרוב האפליקציות.
השלבים הבאים
אחרי שמטמיעים את הלוגיקה בצד השרת של ספק הנתונים המותאם אישית, אפשר ללמוד איך להשתמש בה מלקוחות Apple, Android ואינטרנט.
[null,null,["עדכון אחרון: 2025-08-23 (שעון UTC)."],[],[],null,["App Check has built-in support for several providers: DeviceCheck and App\nAttest on Apple platforms, Play Integrity on Android, and reCAPTCHA Enterprise\nin web apps ([overview](/docs/app-check)). These are well-understood providers\nthat should meet the needs of most developers. You can, however, also implement\nyour own custom App Check providers. Using a custom provider is necessary\nwhen:\n\n- You want to use a provider other than the built-in ones.\n\n- You want to use the built-in providers in unsupported ways.\n\n- You want to verify devices using platforms other than Apple, Android, and the\n web. For example, you could create App Check providers for desktop OSes or\n Internet-of-Things devices.\n\n- You want to implement your own verification techniques on any platform.\n\nOverview\n\nTo implement a custom App Check provider, you need a secure backend\nenvironment that can run the Node.js [Firebase Admin SDK](/docs/admin/setup).\nThis can be Cloud Functions, a container platform such as\n[Cloud Run](https://cloud.google.com/run), or your own server.\n\nFrom this environment, you will provide a network-accessible service that\nreceives proof of authenticity from your app clients, and---if the proof of\nauthenticity passes your authenticity assessment---returns an App Check\ntoken. The specific indicators you use as proof of authenticity will depend on\neither the third-party provider you're using, or the indicators of your own\ninvention, if you're implementing custom logic.\n\nUsually, you expose this service as a REST or gRPC endpoint, but this detail is\nup to you.\n\nCreate the token acquisition endpoint\n\n1. [Install and initialize the Admin SDK](/docs/admin/setup).\n\n2. Create a network-accessible endpoint that can receive authenticity data from\n your clients. For example, using Cloud Functions:\n\n // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken\n exports.fetchAppCheckToken = functions.https.onRequest((request, response) =\u003e {\n // ...\n });\n\n3. Add to the endpoint logic that assesses the authenticity data. This is the\n core logic of your custom App Check provider, which you will need to\n write yourself.\n\n4. If you determine the client to be authentic, use the Admin SDK to mint\n an App Check token and return it and its expiration time to the client:\n\n const admin = require('firebase-admin');\n admin.initializeApp();\n\n // ...\n\n admin.appCheck().createToken(appId)\n .then(function (appCheckToken) {\n // Token expires in an hour.\n const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60;\n\n // Return appCheckToken and expiresAt to the client.\n })\n .catch(function (err) {\n console.error('Unable to create App Check token.');\n console.error(err);\n });\n\n | **Note:** If you encounter a token signing error while creating a new token, make sure your service account has the required permissions. See the [Admin SDK troubleshooting guide](/docs/auth/admin/create-custom-tokens#troubleshooting).\n\n If you can't verify the client's authenticity, return an error (for example,\n return an HTTP 403 error).\n5. **Optional** : Set the time-to-live (TTL) for App Check tokens issued by\n your custom provider by passing an `AppCheckTokenOptions` object to\n `createToken()`. You can set the TTL to any value between 30 minutes and 7\n days. When setting this value, be aware of the following tradeoffs:\n\n - Security: Shorter TTLs provide stronger security, because it reduces the window in which a leaked or intercepted token can be abused by an attacker.\n - Performance: Shorter TTLs mean your app will perform attestation more frequently. Because the app attestation process adds latency to network requests every time it's performed, a short TTL can impact the performance of your app.\n\n The default TTL of 1 hour is reasonable for most apps.\n\nNext steps\n\nNow that you've implemented your custom provider's server-side logic, learn how\nto use it from your [Apple](/docs/app-check/ios/custom-provider),\n[Android](/docs/app-check/android/custom-provider), and [web](/docs/app-check/web/custom-provider) clients."]]
