从SafetyNet迁移至App Check/Play Integrity：两种客户端Token获取方式有何差异？

问题背景 #

我们的Android应用当前使用SafetyNet Attestation API，由于SafetyNet已被弃用，正计划迁移至App Check/Play Integrity API。根据文档理解，整体流程大致一致：从SDK请求token/证明，将其随所有请求发送至可信后端（例如作为HTTP请求头），其余逻辑由后端处理。

但客户端获取token的方式存在两种不同方案：第一种是Firebase文档「保护非Firebase资源」中介绍的主流方式，代码示例如下：

FirebaseAppCheck.getInstance()
            .getAppCheckToken(false)
            .addOnSuccessListener { tokenResponse ->
                val appCheckToken = tokenResponse.token
                val apiCall = yourExampleBackendService.exampleData(appCheckToken)
                // ...
            }

另一种是「从SafetyNet迁移」文档中介绍的方式，代码示例如下：

val nonce: String = ...
val integrityManager = IntegrityManagerFactory.create(applicationContext)
val integrityTokenResponse: Task<IntegrityTokenResponse> =
    integrityManager.requestIntegrityToken(
        IntegrityTokenRequest.builder()
             .setNonce(nonce)
             .build()
).addOnSuccessListener { 
   val token = it.token()
   ...
}

疑惑为何现有SafetyNet用户被建议使用与其他开发者不同的Play Check SDK API，而非统一的API？希望了解这两种方式的差异及适用场景，相关文档在此方面说明不够清晰。

两种方案的核心差异 #

1. 依赖与底层实现 #

• Firebase App Check方案：依赖Firebase SDK，是一层封装层，会自动根据应用环境选择底层验证方式（比如Play Integrity、旧版SafetyNet、DeviceCheck等），不需要开发者直接对接具体验证服务的原生API。
• Play Integrity直接调用方案：依赖独立的Play Integrity SDK，直接对接Google Play Integrity服务，没有中间封装，所有请求参数（如nonce）需要开发者自行处理。

2. 功能与灵活性 #

• Firebase App Check：提供开箱即用的token管理（自动刷新、本地缓存），和Firebase生态服务（Auth、Cloud Functions等）集成更顺畅；但自定义空间有限，比如无法直接控制nonce的生成逻辑（由SDK内部处理）。
• Play Integrity直接调用：完全掌控验证全流程，支持自定义nonce、请求更精细的验证维度（应用完整性、设备完整性等），适合需要高度定制验证逻辑的场景。

3. 后端验证逻辑 #

• Firebase App Check：后端只需对接Firebase的App Check验证API，或在Firebase控制台配置信任来源，验证逻辑由Firebase托管，大幅简化后端开发。
• Play Integrity直接调用：后端需要直接调用Google Play Integrity的验证API，自行解析token内容、校验nonce、应用签名、设备状态等，和原SafetyNet的后端验证流程高度匹配。

为什么SafetyNet迁移用户优先推荐Play Integrity直接调用？ #

1. 流程兼容性：SafetyNet原本就要求开发者自行生成nonce、后端解析验证结果，Play Integrity直接调用的流程和此完全对齐，迁移时只需替换SDK调用和后端API端点，原有nonce生成、后端逻辑可直接复用，大幅降低迁移成本。
2. 功能对齐：SafetyNet提供的设备/应用完整性校验能力，Play Integrity直接调用可完全覆盖，而Firebase App Check的封装会隐藏部分细节，对熟悉SafetyNet的开发者来说，直接用Play Integrity过渡更平滑。
3. 避免额外依赖：如果应用原本未使用Firebase，迁移时无需引入Firebase SDK，减少应用体积和依赖复杂度。

适用场景总结 #

• 选择Firebase App Check：
  • 已在使用Firebase生态服务
  • 希望快速集成，减少自定义逻辑，让Firebase处理大部分验证细节
  • 不需要精细控制验证参数（如nonce）
• 选择Play Integrity直接调用：
  • 从SafetyNet迁移，希望复用原有nonce生成和后端验证逻辑
  • 不需要Firebase服务，想减少额外依赖
  • 需要高度定制验证流程，比如获取更详细的设备/应用状态信息

内容的提问来源于stack exchange，提问作者fraggjkee