手表就在手腕上，为什么还要再掏手机输密码？这就是伴随设备认证要解决的问题。

做支付确认功能的时候，最开始的思路很简单：付钱之前，弹一个指纹或者人脸验证。验证过了就放行。

直到产品提了需求：用户戴着手表的时候，能不能不用再掏手机验证？手表就在手上，点一下手表就能确认。

这时候才意识到，身份认证不是只有"指纹/人脸"这一种。系统还有一套伴随设备认证机制——当用户佩戴着可信的伴随设备（手表、手环）的时候，可以用这个设备来做二次确认，不用再掏手机。

一、伴随设备认证到底是什么

先把概念理清楚：

认证方式	验证对象
指纹/人脸	用户本人
设备锁屏密码	用户本人
伴随设备认证	你是不是带着可信设备的本人

伴随设备认证的逻辑是：你手机上已经解锁了，手腕上还戴着绑定过的手表，系统就知道"是你本人在操作手机"。这时候做一些敏感操作的二次确认，不用再掏手机验证一遍，点一下手表就行。

它不是替代指纹人脸，是补充。低风险的操作，伴随设备就够了；高风险的操作，还是要指纹人脸。

二、认证实例和认证类型

使用 User Authentication Kit 的时候，要先创建认证实例，然后指定认证类型和可信等级。

这段代码解决什么问题： 发起伴随设备认证。
文件： auth/PaymentAuth.ets
用途： 支付二次确认
接入位置： 支付按钮点击后

import userAuth from '@ohos.userIAM.userAuth';

async confirmPayment() {
  const userAuthInstance = userAuth.getUserAuthInstance();
  
  const param: userAuth.AuthParam = {
    challenge: 'xxx',
    authTrustLevel: userAuth.AuthTrustLevel.ATL1,
    authTypes: [userAuth.UserAuthType.COMPANION_DEVICE]
  };

  const result = await userAuthInstance.auth(param);
  if (result.result === userAuth.UserAuthResult.SUCCESS) {
    // 认证通过，继续支付
  }
}

这里 authTypes 指定了用伴随设备认证。可信等级 ATL1 是比较基础的等级，高风险操作要更高等级。

三、可信等级为什么要区分

不是所有业务都用同一个认证强度。

可信等级	典型场景
基础等级	查看个人信息
中等等级	修改设置
高等级	支付、转账、修改密码

伴随设备认证适合中低风险的二次确认。如果是大额支付这种高风险操作，还是要指纹或者人脸。不能所有业务都用同一个认证结果。

四、认证成功不是永久登录

这是最容易踩的坑。很多人觉得：认证通过了，那这个用户就是可信的了，后面所有操作都不用再验证了。

不对。认证结果是有有效期的，而且是和具体业务场景绑定的。

错误做法	风险
认证一次，永久放行	手机放桌上，别人拿起来随便操作
所有业务共用同一个认证结果	低风险认证结果被用到高风险业务
认证成功后不设超时	放了半小时，还认为是刚认证的本人

正确的做法是：每个敏感操作都要单独走认证流程，或者设置合理的有效期。不能一次认证，永久放行。

五、伴随设备断开了怎么办

还有个场景：用户戴着手表认证完了，然后把手表摘了，放一边了。这时候认证状态要不要保留？

不能保留。伴随设备认证的前提是"设备还在身边"。设备都摘了，就不能再认为还是伴随设备认证的可信状态了。

系统会监听伴随设备的连接状态。设备断开了，之前的伴随认证结果就失效了。你不能自己缓存一个"已认证"的状态一直用。

六、几个容易踩的坑

第一个坑：把认证成功当成永久登录。认证是有有效期的，而且是和具体操作绑定的。

第二个坑：所有业务共用同一个认证结果。低风险的认证不能直接给高风险业务用。

第三个坑：认证失败直接退出业务。失败了应该让用户重试，或者换其他认证方式，不要直接把页面关了。

第四个坑：不区分认证等级。查看个设置也要弹指纹，用户体验很差。

第五个坑：重复高频拉起认证。用户点一下就弹一次，太频繁了。要做合理的节流。

这次做支付确认最大的体会是：身份认证不是一个"过了就完事"的开关，是一套分级、分场景、有有效期的安全机制。伴随设备认证只是其中一种方式，适合中低风险的无感确认。用对了能提升体验，用错了就是安全漏洞。