یک ارائه دهنده سفارشی 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);
      });
   

   توجه: اگر هنگام ایجاد یک توکن جدید با خطای امضای رمز مواجه شدید، مطمئن شوید که حساب سرویس شما مجوزهای لازم را دارد. راهنمای عیب‌یابی Admin SDK را ببینید.

   اگر نمی توانید اصالت کلاینت را تأیید کنید، یک خطا را برگردانید (به عنوان مثال، خطای HTTP 403 را برگردانید).

5. اختیاری : با ارسال یک شی AppCheckTokenOptions به createToken() زمان حیات (TTL) را برای نشانه های App Check صادر شده توسط ارائه دهنده سفارشی خود تنظیم کنید. می توانید TTL را روی هر مقداری بین 30 دقیقه تا 7 روز تنظیم کنید. هنگام تنظیم این مقدار، به معاوضه های زیر توجه کنید:

   • امنیت: TTL‌های کوتاه‌تر امنیت قوی‌تری را فراهم می‌کنند، زیرا پنجره‌ای را کاهش می‌دهد که در آن توکن لو رفته یا رهگیری شده توسط مهاجم مورد سوء استفاده قرار می‌گیرد.
   • عملکرد: TTLهای کوتاهتر به این معنی است که برنامه شما به دفعات بیشتری گواهی را انجام می دهد. از آنجایی که فرآیند تأیید برنامه هر بار که انجام می شود، تاخیر را به درخواست های شبکه اضافه می کند، یک TTL کوتاه می تواند بر عملکرد برنامه شما تأثیر بگذارد.

   TTL پیش‌فرض ۱ ساعت برای اکثر برنامه‌ها معقول است.

مراحل بعدی

اکنون که منطق سمت سرور ارائه‌دهنده سفارشی خود را پیاده‌سازی کرده‌اید، نحوه استفاده از آن را از Apple ، Android و مشتریان وب خود بیاموزید.