Triển khai một trình cung cấp tuỳ chỉnh cho tính năng Kiểm tra ứng dụng
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
App Check có hỗ trợ sẵn cho một số nhà cung cấp: DeviceCheck và App Attest trên các nền tảng của Apple, Play Integrity trên Android và reCAPTCHA Enterprise trong các ứng dụng web (thông tin tổng quan). Đây là những nhà cung cấp được biết đến rộng rãi và có thể đáp ứng nhu cầu của hầu hết nhà phát triển. Tuy nhiên, bạn cũng có thể triển khai các trình cung cấp App Check tuỳ chỉnh của riêng mình. Bạn cần sử dụng trình cung cấp tuỳ chỉnh khi:
Bạn muốn sử dụng một nhà cung cấp khác ngoài những nhà cung cấp tích hợp.
Bạn muốn sử dụng các nhà cung cấp tích hợp theo những cách không được hỗ trợ.
Bạn muốn xác minh thiết bị bằng các nền tảng không phải Apple, Android và web. Ví dụ: bạn có thể tạo trình cung cấp App Check cho các hệ điều hành máy tính hoặc thiết bị Internet of Things.
Bạn muốn triển khai các kỹ thuật xác minh của riêng mình trên mọi nền tảng.
Tổng quan
Để triển khai một trình cung cấp App Check tuỳ chỉnh, bạn cần có một môi trường phụ trợ an toàn có thể chạy Firebase Admin SDK Node.js.
Đây có thể là Cloud Functions, một nền tảng vùng chứa như Cloud Run hoặc máy chủ riêng của bạn.
Từ môi trường này, bạn sẽ cung cấp một dịch vụ có thể truy cập vào mạng, nhận bằng chứng về tính xác thực từ các ứng dụng khách của bạn và trả về mã thông báo App Check nếu bằng chứng về tính xác thực vượt qua quy trình đánh giá tính xác thực của bạn. Các chỉ báo cụ thể mà bạn sử dụng làm bằng chứng về tính xác thực sẽ phụ thuộc vào nhà cung cấp bên thứ ba mà bạn đang sử dụng hoặc các chỉ báo do bạn tự tạo ra, nếu bạn đang triển khai logic tuỳ chỉnh.
Thông thường, bạn sẽ hiển thị dịch vụ này dưới dạng một điểm cuối REST hoặc gRPC, nhưng bạn có thể tuỳ ý quyết định chi tiết này.
Tạo một điểm cuối có thể truy cập vào mạng và có thể nhận dữ liệu xác thực từ ứng dụng khách của bạn. Ví dụ: sử dụng Cloud Functions:
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckTokenexports.fetchAppCheckToken=functions.https.onRequest((request,response)=>{// ...});
Thêm vào logic điểm cuối để đánh giá dữ liệu xác thực. Đây là logic cốt lõi của trình cung cấp App Check tuỳ chỉnh mà bạn sẽ cần tự viết.
Nếu bạn xác định ứng dụng là xác thực, hãy sử dụng Admin SDK để tạo mã thông báo App Check và trả về mã thông báo đó cùng thời gian hết hạn cho ứng dụng:
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);});
Nếu bạn không xác minh được tính xác thực của ứng dụng, hãy trả về lỗi (ví dụ: trả về lỗi HTTP 403).
Không bắt buộc: Đặt thời gian tồn tại (TTL) cho mã thông báo App Check do trình cung cấp tuỳ chỉnh của bạn phát hành bằng cách truyền một đối tượng AppCheckTokenOptions đến createToken(). Bạn có thể đặt TTL thành bất kỳ giá trị nào trong khoảng từ 30 phút đến 7 ngày. Khi đặt giá trị này, hãy lưu ý những điểm đánh đổi sau:
Bảo mật: TTL ngắn hơn giúp tăng cường bảo mật, vì TTL ngắn hơn sẽ giảm khoảng thời gian mà kẻ tấn công có thể lợi dụng mã thông báo bị rò rỉ hoặc bị chặn.
Hiệu suất: TTL ngắn hơn nghĩa là ứng dụng của bạn sẽ thực hiện chứng thực thường xuyên hơn. Vì quy trình chứng thực ứng dụng làm tăng độ trễ cho các yêu cầu mạng mỗi khi quy trình này được thực hiện, nên TTL ngắn có thể ảnh hưởng đến hiệu suất của ứng dụng.
TTL mặc định là 1 giờ, phù hợp với hầu hết các ứng dụng.
Các bước tiếp theo
Giờ đây, bạn đã triển khai logic phía máy chủ của trình cung cấp tuỳ chỉnh, hãy tìm hiểu cách sử dụng logic đó từ các ứng dụng Apple, Android và web.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]
