開始在 Apple 平台上,搭配使用 App Check 和 DeviceCheck
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本頁面說明如何使用內建的 DeviceCheck 提供者,在 Apple 應用程式中啟用 App Check。啟用 App Check 後,只有您的應用程式才能存取專案的 Firebase 資源。請參閱這項功能的總覽。
如要搭配使用 App Check 和自訂供應商,請參閱實作自訂 App Check 供應商。
1. 設定 Firebase 專案
如果您尚未將 Firebase 新增至 Apple 專案,請先新增。
在 Apple 開發人員網站上建立 DeviceCheck 私密金鑰。
在 Firebase 控制台的「App Check」部分,為應用程式註冊透過 DeviceCheck 供應商使用 App Check。您需要提供在上一個步驟中建立的私密金鑰。
您通常需要註冊專案的所有應用程式,因為一旦啟用 Firebase 產品的強制執行功能,只有已註冊的應用程式才能存取產品的後端資源。
-
選用:在應用程式註冊設定中,為供應商核發的 App Check 權杖設定自訂存留時間 (TTL)。您可以將 TTL 設定為介於 30 分鐘至 7 天之間的任何值。變更這個值時,請注意下列取捨:
- 安全性:存留時間越短,安全性就越高,因為這樣可縮短攻擊者濫用外洩或遭攔截權杖的時間範圍。
- 效能:TTL 較短表示應用程式會更頻繁地執行認證。應用程式認證程序每次執行時,都會增加網路要求延遲時間,因此 TTL 較短可能會影響應用程式效能。
- 配額和費用:TTL 較短且經常重新認證會更快耗盡配額,而且對於付費服務,可能需要支付更多費用。詳情請參閱「配額與限制」。
大多數應用程式的預設 TTL 為 1 小時,請注意,App Check 程式庫會在 TTL 時間長度的一半左右重新整理權杖。
2. 將 App Check 程式庫新增至應用程式
將 App Check 的依附元件新增至專案的 Podfile
:
pod 'FirebaseAppCheck'
或者,您也可以改用 Swift Package Manager。
請務必使用最新版的 Firebase 服務用戶端程式庫。
執行 pod install
,然後開啟建立的 .xcworkspace
檔案。
後續步驟
在應用程式中安裝 App Check 程式庫後,即可開始向使用者發布更新版應用程式。
更新後的用戶端應用程式會開始在每次向 Firebase 發出的要求中,一併傳送 App Check 權杖,但您必須在 Firebase 控制台的「App Check」App Check 部分啟用強制執行功能,Firebase 產品才會要求權杖有效。
監控指標並啟用強制執行功能
不過,啟用強制執行前,請先確認這麼做不會影響現有的合法使用者。另一方面,如果發現應用程式資源有可疑的使用情形,建議盡快啟用強制執行功能。
如要協助做出這項決定,您可以查看所用服務的 App Check 指標:
啟用App Check強制執行功能
瞭解 App Check 對使用者的影響後,即可啟用 App Check 強制執行:
在偵錯環境中使用 App Check
在註冊應用程式以使用 App Check 後,如果想在 App Check 通常不會歸類為有效的環境中執行應用程式 (例如開發期間的模擬器,或來自持續整合 (CI) 環境),可以建立應用程式的偵錯版本,使用 App Check 偵錯供應器,而非實際的認證供應器。
請參閱「在 Apple 平台上搭配使用 App Check 與偵錯供應器」。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-08-23 (世界標準時間)。
[null,null,["上次更新時間:2025-08-23 (世界標準時間)。"],[],[],null,["This page shows you how to enable App Check in an Apple app, using the\nbuilt-in DeviceCheck provider. When you enable App Check, you help ensure\nthat only your app can access your project's Firebase resources. See an\n[Overview](/docs/app-check) of this feature.\n\nIf you want to use App Check with your own custom provider, see\n[Implement a custom App Check provider](/docs/app-check/ios/custom-provider).\n\n1. Set up your Firebase project\n\n1. [Add Firebase to your Apple project](/docs/ios/setup) if you haven't already\n done so.\n\n2. On the Apple developer site, [create a DeviceCheck private key](https://developer.apple.com/help/account/configure-app-capabilities/create-a-devicecheck-private-key/).\n\n3. Register your apps to use App Check with the DeviceCheck provider in the\n [**App Check**](//console.firebase.google.com/project/_/appcheck) section of the\n Firebase console. You will need to provide the private key you created in\n the previous step.\n\n You usually need to register all of your project's apps, because once you\n enable enforcement for a Firebase product, only registered apps will be able\n to access the product's backend resources.\n4. \u003cbr /\u003e\n\n \u003cbr /\u003e\n\n **Optional** : In the app registration settings, set a custom time-to-live\n (TTL) for App Check tokens issued by the provider. You can set the TTL\n to any value between 30 minutes and 7 days. When changing this value, be\n aware of the following tradeoffs:\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 - Quota and cost: Shorter TTLs and frequent re-attestation deplete your quota faster, and for paid services, potentially cost more. See [Quotas \\& limits](/docs/app-check#quotas_limits).\n\n The default TTL of\n **1 hour**\n is reasonable for most apps. Note that the App Check library refreshes\n tokens at approximately half the TTL duration.\n\n \u003cbr /\u003e\n\n \u003cbr /\u003e\n\n2. Add the App Check library to your app\n\n1. Add the dependency for App Check to your project's `Podfile`:\n\n ```\n pod 'FirebaseAppCheck'\n ```\n\n Or, alternatively, you can use [Swift Package\n Manager](/docs/ios/swift-package-manager) instead.\n\n Make sure you're also using the latest version of any Firebase service\n client libraries you depend on.\n2. Run `pod install` and open the created `.xcworkspace` file.\n\nNext steps\n\nOnce the App Check library is installed in your app, start distributing the\nupdated app to your users.\n\nThe updated client app will begin sending App Check tokens along with every\nrequest it makes to Firebase, but Firebase products will not require the tokens\nto be valid until you enable enforcement in the App Check section of the\nFirebase console.\n\nMonitor metrics and enable enforcement\n\nBefore you enable enforcement, however, you should make sure that doing so won't\ndisrupt your existing legitimate users. On the other hand, if you're seeing\nsuspicious use of your app resources, you might want to enable enforcement\nsooner.\n\nTo help make this decision, you can look at App Check metrics for the\nservices you use:\n\n- [Monitor App Check request metrics](/docs/app-check/monitor-metrics) for Firebase AI Logic, Data Connect, Realtime Database, Cloud Firestore, Cloud Storage, Authentication, Google Identity for iOS, Maps JavaScript API, and Places API (New).\n- [Monitor App Check request metrics for Cloud Functions](/docs/app-check/monitor-functions-metrics).\n\nEnable App Check enforcement\n\nWhen you understand how App Check will affect your users and you're ready to\nproceed, you can enable App Check enforcement:\n\n- [Enable App Check enforcement](/docs/app-check/enable-enforcement) for Firebase AI Logic, Data Connect, Realtime Database, Cloud Firestore, Cloud Storage, Authentication, Google Identity for iOS, Maps JavaScript API, and Places API (New).\n- [Enable App Check enforcement for Cloud Functions](/docs/app-check/cloud-functions).\n\nUse App Check in debug environments\n\nIf, after you have registered your app for App Check, you want to run your\napp in an environment that App Check would normally not classify as valid,\nsuch as a simulator during development, or from a continuous integration (CI)\nenvironment, you can create a debug build of your app that uses the\nApp Check debug provider instead of a real attestation provider.\n\nSee [Use App Check with the debug provider on Apple platforms](/docs/app-check/ios/debug-provider)."]]