通过 BiometricPrompt API，您可以在加密和不加密的情况下实现身份验证。如果您的应用需要更强安全性的保障 (例如医疗类或银行类应用)，则可能需要 将加密密钥同生物特征绑定在一起 来验证用户的身份。否则您仅需向用户提供生物识别身份验证即可。两种方式的代码实现很类似，除了在需要加密时要用到 CryptoObject 实例。
加密版本:
biometricPrompt.authenticate(promptInfo, BiometricPrompt.CryptoObject(cipher))
复制代码
在上述代码中，我们向 CryptoObject 传递了 Cipher 参数，除此之外也支持其余加密对象，比如使用 Mac 或 Signature。
不使用 CryptoObject 的版本:
biometricPrompt.authenticate(promptInfo)
复制代码
若要在 Android 应用中实现生物识别身份验证，请使用 AndroidX Biometric 代码库。虽然 API 可以自动处理不同的认证级别 (指纹、面部识别、虹膜识别等)，但您仍然可以通过 setAllowedAuthenticators() 方法设置应用可以接受的生物认证级别，具体如下面的代码所示。Class 3 (以前被称为 Strong) 级别代表您希望使用生物识别来解锁存储在 Keystore 中的凭证；Class 2 (以前被称为 Weak) 级别代表您只需要使用生物识别来解锁应用，而不依赖于加密技术保护的凭证进一步进行身份验证。还有一个 Class 1 级别，但此级别在应用中并不可用。更多详情，请查看 Android 兼容性定义文档。
fun createPromptInfo(activity: AppCompatActivity): BiometricPrompt.PromptInfo =
BiometricPrompt.PromptInfo.Builder().apply {
setAllowedAuthenticators(BIOMETRIC_STRONG)
// 继续设置其他 PromptInfo 属性，如标题、副标题、描述等。
}.build()
复制代码
加密、auth-per-use (每次验证) 密钥 vs time-bound (时间限制) 密钥
auth-per-use 密钥 是一种被用来执行一次性加密操作的密钥。举个例子，如果您想执行 10 次加密操作，那么就必须解锁 10 次密钥。因此，auth-per-use 就意味着每次使用密钥时，都必须进行认证 (即解锁密钥)。
time-bound 密钥 则是一种在一定的时间段内有效的密钥，您通过向 setUserAuthenticationValidityDurationSeconds 方法传递一个以秒为单位的时间参数，过了该时间后该密钥就需要再次进行解锁。如果您传递的时间参数值为 -1，也就是默认值，那么系统会认为您想要使用 auth-per-use 密钥。在这里若您不想设置为 -1，那么我们建议您至少设置为 3 秒，这样系统会遵循您所设置的时间。想要了解更多创建 time-bound 密钥的方法，请参考 Jetpack Security 中关于 MasterKeys 的内容。
通常，即前面提到的 -1 的情况时，您通过向 BiometricPrompt.authenticate() 方法传递一个 CryptoObject 参数来请求 auth-per-use 密钥。然而，您也可以不使用 CryptoObject，而是设置一个很短的时间参数 (比如 5 秒)，来将 time-bound 密钥当作 auth-per-use 密钥来使用。这两种方法对于验证用户身份来说实际上是等同的，如何选择取决于您设计应用交互的方式。
让我们看看这两种不同类型的密钥是如何工作的: 当您使用 CryptoObject 时，只有某个特定操作才能够解锁密钥。这是因为 Keymint (或者是 Keymaster) 获取了一个带有特定 operationId 的 HardwareAuthToken (HAT)。当密钥被解锁后，您只能使用密钥去执行那些被定义为 Cipher/Mac/Signature 的操作，并只能执行一次，因为这是一个 auth-per-use 密钥。若不使用 CryptoObject，那么被发送到 Keymint 的 HAT 就没有 operationId，此时，Keymint 会去查找一个带有有效时间戳 (时间戳 + 密钥使用期限 > 当前时间) 的 HAT，在有效时间内，您都能够使用该密钥，因为它是一个 time-bound 密钥。
这样看上去，似乎只要在有效的时间窗口内，任何应用都可以使用 time-bound 密钥。但实际上，只要不是用户空间 (user-space) 受到损害，不用担心某个 X 应用使用了某 Y 应用的密钥或操作。Android 框架不会允许其他应用获取或者初始化另一个应用的操作。
在本篇文章中，我们介绍了:
-
只有用户名 + 密码的认证方式存在问题的原因；
-
在应用中选择使用生物识别身份验证的原因；
-
不同类型应用在
设计认证方式时的注意事项；
原因； -
在应用中选择使用生物识别身份验证的原因；
-
不同类型应用在[外链图片转存中…(img-yNxSCYSH-1642933162675)]
设计认证方式时的注意事项；