HarmonyOS 7 + User Authentication Kit + Asset Store Kit 技术干货：生物认证、敏感操作授权与关键资产安全闭环【鸿蒙心迹】

2601_96710770

414人浏览 · 2026-09-29 11:32:19

2601_96710770 · 2026-09-29 11:32:19 发布

这篇我想聊一个很容易被低估的话题：很多应用不是没有“安全功能”，而是没有把“认证、授权、资产存储、访问审计”真正串起来。表面看只是多调几个接口，实际做工程时，它更像一条完整的安全访问链。

一、敏感数据保护，难点从来不是“加密”两个字

做账号系统、云服务接入、本地密钥管理时，大家都会想到“要安全”。

但真进入业务，安全不是一个抽象词，而是几个很具体的问题：

API 密钥要不要落本地？
登录凭据和普通缓存数据能不能放在一起？
每次读取敏感内容都要求用户认证，会不会太打断体验？
哪些操作必须做指纹 / 人脸 / 锁屏口令验证？
认证成功后，访问窗口应该维持多久？
访问过哪些关键资产，需不需要留痕？

这些问题如果不在设计阶段想清楚，后面很容易出现两种极端：

一种是为了方便，所有数据都能直接读；
另一种是为了安全，所有操作都强行二次验证，结果把体验做崩。

所以我后来给自己定了一个很实用的拆法：

User Authentication Kit 负责“你是不是本人”；
Asset Store Kit 负责“资产放哪儿、怎么存、怎么读”；
业务层策略 负责“什么场景必须认证、什么时候允许继续访问”。

二、先分清“普通数据”和“关键资产”

我做这类功能时，不会把所有数据都扔进一个统一存储里。

因为“配置项”“页面缓存”“用户偏好”跟“API 密钥”“第三方登录凭据”“本地加密数据”完全不是一个安全级别。

我通常会这样分：

普通数据：Preferences、数据库缓存、页面表单中间态；
重要数据：账户标识、业务状态快照、最近操作记录；
关键资产：API_KEY、refresh token、加密材料、本地受保护文档索引。

真正需要 Asset Store 保护的，应该是第三层。

这件事如果前期不分，后面越做越乱。因为安全策略一定是跟“数据价值”绑定的，而不是跟“代码写在哪个页面”绑定的。

三、认证入口别写散，敏感操作前做统一校验

最怕的一种写法，是每个按钮里自己去判断要不要认证。

这种写法短期很快，长期会很难维护。你今天有“查看 API 密钥”，明天又有“导出本地凭据”，后天还有“删除关键资产”。如果每个操作都自己判断，认证逻辑马上到处开花。

我更建议把“敏感操作前认证”做成一层统一服务。

例如下面这段代码，核心不是 API 写法，而是把认证动作从页面按钮里抽出来：

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

export class AuthService {
  async authenticateForSensitiveAction(): Promise<boolean> {
    try {
      const result = await userAuth.getUserAuthInstance().auth({
        challenge: new Uint8Array([1, 2, 3, 4]),
        authType: [
          userAuth.UserAuthType.FINGERPRINT,
          userAuth.UserAuthType.FACE,
          userAuth.UserAuthType.PIN
        ],
        authTrustLevel: userAuth.AuthTrustLevel.ATL2
      });
      return result.result === 0;
    } catch (err) {
      console.error(`authenticate failed: ${JSON.stringify(err)}`);
      return false;
    }
  }
}

这个思路的好处很明显：

哪些认证方式可用，由认证服务统一决策；
页面只关心“是否通过”；
后续切换认证策略，不用满工程改按钮事件。

四、Asset Store 不只是“存一下”，更重要的是访问边界

很多人会把安全存储理解成“把字符串存进去，再取出来”。

这理解不算错，但太浅了。

在工程里，Asset Store 更大的价值是：给关键资产一个独立、受控、可组合认证策略的存取空间。

像 API 密钥、登录凭据这类信息，不该和普通配置一起暴露在宽松访问链路里。

我一般会把资产层再封成单独服务，例如：

import asset from '@ohos.security.asset';

export class AssetService {
  async saveApiKey(value: string) {
    const attrs = new Map<string, Uint8Array | number>();
    attrs.set(asset.Tag.ALIAS, new TextEncoder().encode('api_key'));
    attrs.set(asset.Tag.SECRET, new TextEncoder().encode(value));
    attrs.set(asset.Tag.ACCESSIBILITY, asset.Accessibility.DEVICE_POWERED_ON);
    await asset.add(attrs);
  }

  async queryApiKey(): Promise<string> {
    const query = new Map<string, Uint8Array>();
    query.set(asset.Tag.ALIAS, new TextEncoder().encode('api_key'));
    const result = await asset.query(query);
    return new TextDecoder().decode(result.secret as Uint8Array);
  }
}

这里真正关键的是：资产访问不直接暴露给页面，而是放在统一服务层，由认证服务作为前置门禁。

也就是说，读取关键资产之前，应该先问一句：当前操作有没有通过身份验证？