HarmonyOS 鸿蒙Next中这种说法对吗，关于底层结构

HarmonyOS 鸿蒙Next中这种说法对吗，关于底层结构

API 和权限调用不对应：底层主要靠 Token 强制校验

这部分鸿蒙底层能防得更直接。

OpenHarmony 的权限机制里，每个应用有一个 TokenID，AccessTokenManager 会基于 TokenID 管理应用 ID、用户 ID、APL、权限授权状态等；当应用访问资源时，系统用 TokenID 获取授权状态并做鉴权。

所以不是“应用市场审核通过了就一路放行”，而是：

App 调用某个系统 API
        ↓
系统服务识别这个 API 需要什么权限
        ↓
拿调用方 TokenID 查授权状态
        ↓
有对应权限才放行，没有就拒绝

举例：

App 声明了相机权限
但实际调用定位 API
        ↓
定位服务检查的是定位权限，不是相机权限
        ↓
Token 里没有定位授权
        ↓
调用失败

OpenHarmony 的权限管理组件也明确提供 VerifyPermission 这类能力，用于检查指定应用是否已被授予指定权限；系统服务/API 在鉴权时会依赖这种权限校验能力。

所以如果是App 声明了 A 权限，但调用需要 B 权限的 API → 系统服务检查 B → Token 没有 B → 拒绝


更多关于HarmonyOS 鸿蒙Next中这种说法对吗，关于底层结构的实战教程也可以访问 https://www.itying.com/category-93-b0.html

12 回复

整体来说是正确的，比如按照官方说法是：

ATM (AccessTokenManager) 是统一权限管理组件，每个应用分配唯一 TokenID；AccessToken 内存储 APPID、UID、用户 ID、APL 等级、全量授权权限清单；全系统 API 鉴权依托 TokenID 查表校验权限。

提供核心能力：根据 TokenID 查询权限、运行时鉴权VerifyPermission/CheckPermission，安装市场仅做配置合规校验，运行调用 API 才基于 Token 实时鉴权。

你可以看一下下面的gitee上面访问控制简介，个人觉得描述没有问题：

security_access_token: ATM(AccessTokenManager)是OpenHarmony上基于AccessToken构建的统一的应用权限管理能力。

更多关于HarmonyOS 鸿蒙Next中这种说法对吗，关于底层结构的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


背景知识：

对的。
OpenHarmony 权限核心是 ATM(AccessTokenManager)。

ATM 以 TokenID 为 key，管理该应用的：

  • 应用 ID（APPID）
  • 用户 ID（子用户）
  • 应用分身索引
  • APL（Ability Privilege Level）
  • 各权限的授权状态

OpenHarmony 中，ATM 为每个应用实例分配唯一 TokenID，并用它管理对应 AccessToken（含 APPID / 用户 ID/APL/ 权限状态）；资源访问时系统用 TokenID 查权限并鉴权。

通过Token进行强制校验，系统能够在每一次API请求时都精确地核对调用者的身份和权限，从而从根本上保证了“API和权限调用”的一致性与安全性

说得挺好~把鸿蒙（OpenHarmony）权限机制最核心的“每次调用校验”逻辑讲得很清楚。

  • 不是靠“声明了什么”来放行，而是靠“Token里有什么”来放行。
  • 每一次敏感 API 调用，系统服务都会用调用方的 TokenID 实时查询 AccessTokenManager，验证当前调用所需的具体权限是否已被授予。
  • 与 App 在配置文件中声明了哪些权限无关，只与 TokenID 里实际被授权的权限列表有关。

大体上没毛，但是还应该有用户是否授权的观念吧

这段说法整体方向是对的，但如果是给开发者或者做技术分享，我觉得可以稍微修正一下表述，避免让人误解。更严谨的说法应该是：

HarmonyOS/OpenHarmony 的权限控制并不是“应用市场审核通过后就一路放行”，而是基于 TokenID 的运行时鉴权机制。应用访问系统能力时，对应系统服务会根据调用方 TokenID 查询权限授权状态、APL 等信息进行校验。即使应用声明了某个权限，如果调用的系统能力需要其他权限，或者不满足 APL 等限制条件，也会被系统拒绝访问。

这个版本在技术上会更准确一些。

是对的，OpenHarmony 底层 权限鉴权逻辑就是这样的。

OpenHarmony 主要是遵循一 API 对应一权限、按 Token 精准鉴权：应用仅声明并获得 A 权限，调用依赖 B 权限的 API 时，系统校验 B 权限授权状态，因 Token 无 B 权限直接拦截调用，不受已有 A 权限影响。

cke_541.png

这段理解大方向是对的，但建议补两个边界条件。

HarmonyOS/OpenHarmony 的运行时权限不是“市场审核通过后统一放行”，系统服务会按调用方身份和目标 API 所需权限做校验；应用声明了 A 权限，并不能调用需要 B 权限的能力。

但完整链路通常包含几层：

  1. module.json5 里声明权限，只是具备申请/使用该权限的前提。
  2. user_grant 权限还需要用户授权。
  3. system_core、受限权限、ACL 等权限还会受应用类型、证书、APL 或开放能力约束。
  4. API 调用时系统服务再按调用方 TokenID/权限状态做校验。

所以可以概括为：声明是入口，授权是状态，系统服务鉴权是最终执行点。不要把上架审核、权限声明和运行时授权混成一个动作。

不太清楚描述的内容，但是权限不是APP声明了就管用，有些权限必须得用户使用时，实时手动授权才行，这个不是市场通过了某个权限，应用就具有某个权限了。

同意，

需要提供具体“说法”的原文才能判断对错。鸿蒙Next底层采用微内核架构，结合分布式软总线，与Linux宏内核或传统RTOS有本质区别。若无明确表述，无法评估准确性。

说法正确。HarmonyOS Next（基于OpenHarmony）的权限模型确实以TokenID为核心。系统在运行时为每个应用生成唯一的TokenID，AccessTokenManager基于它管理应用身份、APL等级和权限授予状态。当应用调用API时，系统服务会动态识别所需权限，通过TokenID查询该应用是否已获得对应授权，未授权则直接拒绝，不依赖应用声明的权限列表。因此即便应用声明了相机权限，若实际调用定位API，定位服务校验的是定位权限，Token中没有授权就会失败。这一机制确保权限校验在系统底层强执行，与市场审核环节解耦。

回到顶部