最近,我决定为我为一个小型<300个用户组运行的iOS应用程序启用App on Firebase。对于iOS项目,Firebase有两个用于App、DeviceCheck和Attest的选项。通过从我的苹果开发者帐户上传我的Auth密钥,我就可以毫无问题地打开DeviceCheck。所有的事情似乎都没有问题,但我不知道在引擎盖下到底发生了什么,因为Firebase文档只解释了如何设置它,并且我希望确保它正确工作。
有人能向我解释一下,在这个场景中,设备检查是如何与Firebase一起工作的吗?它与iOS应用程序有什么不同,可以证明Firebase也支持吗?
Firebase iOS应用程序检查文档:
发布于 2022-01-26 15:40:38
Firebase应用程序如何使用iOS DeviceCheck检查?
简而言之,SDK在发出请求时会向AppCheck SDK请求一个特殊的AppCheck令牌。当App配置为使用DeviceCheck时,它将在DeviceCheck框架的帮助下生成请求的令牌。请注意,DeviceCheck是苹果创建的一个框架。
我不明白引擎盖下面到底发生了什么.
这里有一些更多的细节来帮助澄清问题:
AppCheck SDK使用AppCheckProviders生成应用程序检查令牌。有4种类型的AppCheckProvider:
对于某些支持AppCheck执行的Firebase (例如Firestore),在发送请求时,它们将向AppCheck SDK请求一个AppCheck令牌。AppCheck SDK使用上面列出的4个AppCheckProviders中的一个生成令牌。您可以使用AppCheck的AppCheck.setAppCheckProviderFactory(_:) API自定义使用哪个提供程序。我在回答中写了更多关于它的目的的文章。
..。我想确保它正常工作
如果您能够在Firebase控制台中看到请求度量,则AppCheck将正确实现并工作。如果启用了强制执行,则应该开始在度量图中看到一些强制请求。
有人能解释一下在这种情况下设备检查是如何使用Firebase的吗.
因此,当AppCheck SDK使用DeviceCheckProvider (此提供程序是默认的!)时,AppCheck SDK将在苹果的DeviceCheck框架的帮助下创建AppCheck令牌。
它(设备检查)与iOS应用程序有何不同,证明Firebase也支持?
这里的答案可以在苹果的DeviceCheck文档中找到。
简而言之,区别在于这两个名字。
设备检查对于验证请求是否来自实际的设备非常有用。例如,假设您有一个iOS应用程序,并且正在与DeviceCheckProvider一起使用Firebase AppCheck。如果启用强制执行,则只有来自实际设备的请求才能成功。因此,如果我试图通过curl‘从命令行发出请求来访问后端API,它应该会被拒绝,因为没有令牌可以确认请求来自实际设备,这样可以防止后端被滥用。
App验证了设备检查框架的一部分,并通过证明请求来自https://developer.apple.com/documentation/devicecheck/establishing_your_app_s_integrity,提供了更高级的验证。要理解为什么这是有用的,请考虑您的iOS应用程序配置为在DeviceCheckProvider中使用Firebase AppCheck。假设黑客将你的应用程序重新编译到一个实际的设备上。在这种情况下,DeviceCheck的有效性降低了,因为从这个恶意副本发送的请求技术上来自“实际设备”,因此将生成一个有效的令牌。应用程序证明了更高级的认证可以证明请求来自于应用程序的有效实例。在本例中,黑客的副本将不是有效的实例。
此时,您可能会想知道,当您可以使用更高级的应用程序验证时,为什么要使用DeviceCheck ?原因是操作系统可用性: App验证只适用于iOS 14.0+。
我希望这回答了你的问题!
https://stackoverflow.com/questions/70692509
复制相似问题